[2019.02.19] 객체지향의 사실과 오해 (1장~4장)

객체지향 개발 5대 원리 : SOLID

S	단일 책임
O	개방, 폐쇠
L	다형성
I	인터페이스 분리
D	Dependency injection

---

1장

객체지향의 목표 : 목표를 달성하기 위한 협력과 맡은바 역할과 책임을 다하는 것

객체지향의 시작 : 적절한 객체에게 적절한 책임을 할당하는 것

객체는 자율적이고 협력적이여야한다.

협력적이란 것은 개방적이란 것이다. 

자율적이란 것은 외부의 간섭받지않고 스스로 결정가능하다는 것이다.

request = 메시지 

request caller = sender

request callee = reciever

request 처리 = 메소드

'클래스' 지향 프로그래밍이 아니라 '객체' 지향 프로그래밍임을 유념해라.

어떤 클래스가 필요한가가 아닌 어떤 객체가 어떻게 통신해서 협력할 것인가를 고민해라.

"클래스, 메소드" < "역할, 책임, 협력"

---

2장

객체는 행동에의해 객체가 변하더라도 상태 변경과는 무관하게 식별 가능해야한다.

식별자

 = 참조 객체

 = 엔티티

프로퍼티	멤버 변수
프로퍼티 값	멤버 변수 값
연결	참조 멤버 변수
속성	원시 멤버 변수
상태	특정 시점에 객체가 가지는 프로퍼티 값들  들과거에 얽매이지 않고 현재 객체의 행동방식을 이해할 수 있는 요소
쿼리	객체의 상태 조회
명령	객체의 상태 수정

캡슐화의 목표 : 객체는 자율적이다. 

다른 객체의 상태에 직접 접근할 수 없고 상태를 직접 변경 할 수도 없다. 

다른 객체의 상태를 변경하고 싶다면 다른 객체가 알아서 하도록 해라. 

다른 객체가 상태 변경 여부도 알아서 판단하도록해라. 

외부에서 객체에 접근할 수 있는 수단은 행동 밖에 없다.

객체는 기계가 되야한다. 라디오를 사용할 때 라디오 내부가 어떻게 돌아가는지 몰라도 버튼하나만 눌러도 재생되는 것처럼. 어떤 방식으로 라디오가 동작할지는 라디오 마음이다.

객체지향은 현실 세계의 모방이 아니다.

객체지향은 현실 세계를 참조할 뿐 다른 세계를 창조하고 시뮬레이션 하는 것이다.

---

3장

목적에 집중해라. 몰라도되는 정보는 무시할 수있도록해라. 본질만을 드러나게 하라. 이것이 추상화다.

리차드 파인만 : 현실은 복잡하다. 법칙은 단순하다. 버릴게 뭔지 알아내라.

객체	개념이 적용될 수 있는 구체적인 사물
인스턴스	개념이 적용된 구체적인 사물

개념	타입
심볼	개념의 이름
내연	개념의 설명
외연	인스턴스 집합
데이터 타입	메모리 안의 데이터를 타입에 따라 분류하는데 사용하기 위한 메타데이터

1. 객체의 타입을 결정하는 것은 객체의 행동뿐이다. 

2. 객체가 어떤 데이터를 보유하는지는 타입을 분류하는데 중요하지 않다. 

3. 객체의 행동, 즉 책임만으로 타입을 분류한다.

4. 그런데 같은 타입으로 분류된 객체가 내부 표현 방식에 따라 동일한 메시지에대해서 처리 루틴을 다르게 처리해줘야한다면? 어떻게 처리해야할까? 

5. 그래서 다형성이 생겨났다.

* 다형성이란 동일한 메시지를 서로 다른 방식으로 응답할 수 있는 능력을 말한다.

트렌드 변화

데이터 주도 설계

->책임 주도 설계

일반화-특수화 관계

슈퍼 타입 : 일반화

서브 타입 : 특수화

행위적 호환성이 만족되야한다.

---

4장

문맥을 고려해서 상태와 행동을 고민하라

어떤 대상에대한 요청은 그 대상이 요청을 처리할 책임이 있음을 암시한다.

책임 : 응집도 있는 행위의 집합

1. 무엇을 알고 있는가

2. 무엇을 할 수 있는가

책임은 객체의 public 인터페이스를 구성한다.

책임은 객체가 수행해야할 행위를 개략적으로 서술한 것

메시지는 이를 구체적으로 변환한 것

역할 : 책임의 집합

역할이 재사용 가능한 설계를 낳는 중요한 요소

동일학 역할을 수행할 수 있다

= 동일한 책임의 집합을 수행할 수 있다

객체가 대체 가능하기 위해선 역할이 수행하는 모든 책임을 동등하게 수행할 수 있어야한다.

= @Override 해야한다.

= 행위 호환성

객체의 존재 이유 : 행위를 수행하고 협력에 참여하기 위해서

객체지향은 클래스(정적)와 클래스간의 관계 표현하는 시스템에 중점을 두는게 아니다.

클래스는 동적인 객체를 표현하기위한 프로그래밍 언어일 뿐이다.

King 이라는 클래스를 만들때 외모가 어떻고 키가 어떻고 생김새는 중요하지 않다.

King 이 하는 행위에 집중하라

객체 지향 설계 기법

RDD (책임 주도 설계)	시스템의 책임을 객체의 책임으로 변환  책임을 처리해줄 협력자를 찾아 할당  역할, 책임, 협력에 집중하는 것
TDD (테스트 주도 개발)	테스트코드를 작성함으로서 역할, 책임, 협력을 이끌어내고   이것이 적합한지 피드백 받는 설계 기법.  즉 RDD를 실현하기 위한 개발론
디자인 패턴	반복적으로 사용하는 역할, 책임, 협력 구조들의 해결 기법 정의  RDD의 결과물

문득 드는 생각 : 왜 TDD가 좋은가.

* Zero base에서 프로젝트 설계를 위해 UML을 그린다 생각해보자.  클래스별로 메소드는 이래야하고 저래야하고 상상하면서 정의해야한다.  - 필요할 줄 알았던 메소드가 필요없고 알고보니 필요한 메소드가 생긴다.  - 메소드에 들어가야하는 파라미터도 수시로 바뀐다.  TDD를 하면 이를 직접 코드로 짜보면서 명확히 구현해 나가 볼 수 있다.

TDD : 응집도가 높고 결합도가 낮은 클래스로 구성된 시스템 개발이 가능하게 한다.

But. TDD를 할 때 역할, 책임, 협력이라는 관점에서 객체를 바라보지 못하면 무의미하다.