배운 것

• 메시지가 객체를 결정한다.
  -> 객체가 최소한의 인터페이스를 가질 수 있게 된다.

• 행동이 상태를 결정한다.
  -> 객체는 충분히 추상적인 인터페이스를 가질 수 있게 된다.

• 협력이 객체의 행동을 결정하고 행동이 상태를 결정한다. 그 행동이 바로 객체의 책임이 된다.

• 객체가 존재하지만 역할이 따로 존재하는 이유
  : 예를 들어서 할인 요금을 계산하라는 메시지를 보낼때 할인 요금을 계산할 수 있는 객체는 AmountDiscountPolicy와 PercentDiscountPolicy 모두 할인 요금을 계산하라는 메시지를 수신할 수 있지만 서로 다른 두개의 협력을 구현한다면 코드가 중복될 것이기에 '역할' 이라는 일종의 바꿔 끼울 수 있는 슬롯을 만드는 것이다.

• 역할을 구현하는 가장 일반적인 방법은 추상클래스와 인터페이스를 사용하는 것이다.
  -> 추상클래스 : 모든 객체들이 공유하는 상태와 행동의 기본 구현이 존재
  -> 인터페이스 : 공통의 구현이 필요없고 책임의 목록만 정의

• 여러 종류의 객체에 의해 수행될 필요가 있다면 그 자리는 역할이되지만, 단지 한 종류의 객체만이 협력에 참여할 필요가 있다면 그자리는 객체가 된다.

• 변경될 가능성이 높은 부분 = '구현' / 상대적으로 안정적인 부분 = '인터페이스'

• 응집도 : 모듈에 포함된 내부 요소들이 연관돼 있는 정도, 변경이 발생할 때 모듈 내부에서발생하는 변경의 정도

• 결합도 : 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는 정도, 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도

• getter와 setter를 사용해서 밖에서 처리하는 것이 아닌 객체가 자기 스스로 책임을 질 수 있도록 설계한다

• 내부 구현의 변경이 외부로 퍼져나가는 파급 효과는 캡슐화가 부족하다는 증거이다.

• 객체의 속성값을 외부로 유출하는 것은 캡슐화를 어긋나지만 메서드의 파라미터와 반환값 또는 메서드명에서도 내부 구현을 노출시키면안된다.

책임을 할당하는 방법 page.82

1. 시스템이 사용자에게 제공하는 기능을 시스템이 담당할 하나의 책임으로 생각
2. 그 책임을 메시지로 협력을 시작한다.
3. 정해진 메시지와 관련된 정보를 가장 많이 알고 있는 객체에게 책임을 할당한다.
4. 정해진 객체에게 필요한 정보에 대한 메시지를 발견하고 외부로 요청한다.
5. 이 메시지를 처리하는 정보를 가장 많이 알고 있는 전문가를 선택한다.
6. 협력에 필요한 메시지를 찾고 메시지에 적절한 객체를 선택하는 과정을 반복한다.

책임 주도 설계 방법 page.84

• 시스템이 사용자에게 제공하는 기능인 시스템 책임을 파악한다( 가장 큰 책임 )
• 시스템 책임을 더 작은 책임으로 분할한다.
• 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.
• 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적잘한 객체 또는 역할을 찾는다.
• 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.

궁금한 것

• 객체의 아는 것과 하는 것을 정의하는 것과 협력을 정의하는 것중 객체를 정의하는 것이 먼저인가