객체 지향에 대한 캡슐화, 상속, 추상화, 다형성, 런타임에 의존한다, 합성을 통해 결합... 같은 부분은 너무 유명해서 객체지향의 본질을 해치는 경우가 많다.
역할+책임+협력 을 이해해야 한다
시작 과정에서는 역할, 책임, 협력을 고려하고 설계 해야지, 클래스같은 것들을 너무 집중한다면, 추후에 변경에 대응하기 어려워 진다.
메세지를 보내며 수행하는 상호작용=협력
객체가 협력에 참여하기 위한 수행하는 로직=책임
협력하에 수행하는 책임들이 모여 객체가 수행하는 역할을 구성
메세지 전송을 통해서 진행함
상호작용=>메서드를 실행해 역할 수행 => 캡슐화
설계는 코드만 보는 과정이 아니다.
협력은 객체를 설계하는 것에 있어서 일종의 문맥을 제공한다
책임은 객체를 설계하기 위해 필요한 문맥인 협력이 갖추어진 이후에 일어난다
협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 한다
객체에 의해 정의되는 응집도 있는 행위의 집합
객체가 유지할 정보와 수행할 정보를 개략적으로 서술한 문장
doing, knowing을 하는 것
객체지향에서 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는 것
책임 할당은 가장 그 정보를 잘 알고 있는 사람에게 맡기는 것. 정보 전문가 패턴
이렇게 책임만을 고려한 설계를 Responsibility Driven Design 이라고 한다.
책임을 파악하고, 더 작은 책임으로 분할하고, 분할된 책임을 수행하기 좋은 역할을 찾아 분할한다. 객체가 책임을 수행하는 도중, 다른 객체의 도움이 필요할 경우 이를 책임질 적절한 객체 또는 역할을 찾는다 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 된다
메시지가 객체를 결정한다
객체가 최소한의 인터페이스를 가질 수 있다. 필요한 메시지+행동까지 나오기 전에 public 인터페이스가 아무것도 없다.
추상적인인터페이스를 가질 수 있다. What 보다 how를 노출해서는 안되는데, 이를 구현하기 쉽다
행동이 상태를 결정한다
객체가 존재하는 이유는 협력에 참여하기 위해
얼마나 적합한 객체를 만들었느냐= 책임을 얼마나 할당했느냐, 책임이 적절한지= 협력에 얼마나 적절한가를 보면 된다
상태=> 행동으로 가는 것이 아니라 행동=>상태로 가면 더 편하다
내부 구현에 초점을 맞춘 설계 = Data Driven Design
캡슐화를 위반하지 않도록, 구현의 결정을 미루고, 객체의 행위를 먼저 고려해야한다.
협력 관계 속엣어 무엇을 제공하고, 무엇을 얻어야 하는지를 고민해야 훌륭한 설계를 만들 수 있다.
개별 객체의 상태와 행동이 아닌 시스템의 기능을 위한 다양한 것들을 만들어 내야 한다. 상태는 행동을 정상적으로 하기 위한 필요한 재료다 행동을 고려해야 한다.
역할 객체가 갖게되는 책임의 집합을 역할로 한다.
erd같은 관계를 만들고, 그 관계에서 어떤 역할을 할 지 추후에 연결하는 것이 좋아보임
역할은 협력 안에서, 바꿔끼울 수 있는 일종의 슬롯
추상화라는 점을 주목해야 한다
역할을 구현하는 가장 일반적인 방법은 추상 클래스와 인터페이스를 사용하는 것
역할이 여러 객체를 포함할 수 있는 추상화가 될 수도 있다.
수행할 역할이 있는 대상이 1종류라면 객체를, 여러 종류라면 역할이라고 칭한다.
