CH.1 협력하는 객체들의 공동체

• 객체지향의 핵심은 적절한 책임을 가진 객체 간의 유연하고 견고한 협력 관계를 구축하는 것이다.
• 중요한 것은 메시지를 주고 받는 객체들의 동적인 관계를 구성하는 것이다.
• 객체의 역할, 책임, 협력에 집중하자. 객체를 지향해야지 클래스를 지향하지 말자.

CH.2 이상한 나라의 객체

• 객체는 상태, 행동, 식별자를 지닌다. 즉, 식별 가능한 개체 또는 사물이다.
• 클래스, 필드와 메서드를 떠올리는건 또 다른 의미로 구체적인 것에 의존하는 게 아닐까?
• 객체의 상태를 변화시킬 수 있는건 자신뿐이다. → 캡슐화
  • 또한 그 트리거가 되는것이 수신된 메시지이다.
  • 또한 그 메시지 송신자는 자신의 요구를 요청하는 것 뿐, 메시지에 반응해서 상태를 변경하는 것은 온전한 수신자 측의 자율에 맡긴다. → 자율적인 객체들이 협력을 유연하고 간결하게 만든다.
• 객체를 설계할 때 상태와 행동 중 상태를 먼저 고려하면 설계에 나쁜 영향을 미친다.
  1. 캡슐화가 저해된다. → 상태에 초점을 맞출 경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못할 확률이 높다.
  2. 객체가 협력 관계 측면에서 질이 떨어진다. → 객체가 필요한 이유는 다른 객체와의 협력이 주된 목표인데 상태를 먼저 고려한다는 것은 협력이라는 문맥에서 벗어난 객체를 설계하게 된다.
  3. 객체의 재사용성이 떨어진다. → 객체의 재사용성은 다양한 협력에 참여할 수 있는 능력에서 나온다. 근데 상태 먼저 고려했다? → 다양한 협력에 참여하기 어렵다.
• 객체를 설계할 때는 행동에 초점을 맞추자! → 객체는 다른 객체와 협력하기 위해 존재한다.
  • 협력에 필요한 행동을 생각한 후 그에 필요한 정보가 무엇인지 고려하며 상태를 정의하자.
  • 행동이 상태를 결정한다.
• 소프트웨어의 객체는 현실 세계 객체의 특징을 추상화하여 필요한 부분만 추출해 사용하는 개념이 아니다. 추상화를 이렇게 설명하기도 하지만 사실은 소프트웨어에서는 현실 세계에서 모방한 객체보다 더 많은 일들을 하게끔 만들 수 있다. 따라서 굳이 말하자면 은유이며 이를 통해 표현적 차이를 줄이는 행위이다. → 표현적 차이를 줄이면 소프트웨어 상의 객체를 조금 더 잘 이해할 수 있어 유지보수성이 높아진다.

CH.3 타입과 추상화

• 추상화는 어떤 것을 잘 이해하기 위해 복잡한 것을 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다.
• 객체지향에서의 타입은 행동을 기준으로 정의된다. 같은 행동을 할 수 있다면 같은 타입이라고 보는 것이다. 이는 다형성과 관련된 이야기이기도 하다.
• 다형성은 동일한 요청에 대해 서로 다른 방식으로 응답할 수 있는 능력을 뜻한다. 즉, 다형적인 객체는 동일한 타입에 속한다.
• 이렇게 내부 데이터와 무관하게 행동만이 고려 대상이라는 것은 외부에 데이터를 감추어야한다는 뜻이다. 따라서 훌륭한 객체지향 설계에서는 외부에 행동만을 노출시켜야한다. 이 원칙을 흔히 캡슐화라고 한다.
• 캡슐화는 객체를 행동에 따라 분류하기 위한 기본적인 원칙인 것이다.