[오브젝트: 코드로 이해하는 객체지향 설계] 를 읽고 정리한 내용입니다.

객체, 설계

한 가지 염두에 둬야 할 점은 이 책에서 제시하는 방법이 객체지향을 구현하기 위한 유일한 방법은 아니라는 점입니다.

이 책은 코드를 개발하는 우리가 객체지향 패러다임이라는 용어를 사용할 때 완벽하게 동일하지는 않더라도 어느 정도 유사한 그림을 머릿속에 그릴 수 있는 기반을 제공할 것이다.

간단히 말해 프로그래밍 패러다임은 혁명적이 아니라 발전적이다. 이런 사실은 비록 객체지향 패러다임을 주로 사용한다고 하더라도 다른 패러다임을 배우는 것이 도움 될 것이라는 사실을 암시한다.

객체지향이 무조건 답은 아님. 이라는 걸 말해주려는 것 같다. 문제를 해결 할 때 접근하는 방식은 다양하고, 모든 곳에 들어 맞는 정답은 없다.

티켓 판매 애플리케이션 구현하기

코드로 보기

이것은 객체 사이의 의존성과 관련된 문제이다. ... 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체로 인해 함께 변경될 수 있다는 사실이 내포되어 있다.

• 예시: 초기 Theater 클래스
  • 불필요한 의존성이 많이 존재한다. == 객체 사이에 결합도가 높다.
  • 결합도가 높으면 함께 변경될 확률도 높아진다. == 유지보수가 어려워진다.
• 개선방법
  • Theater가 Audience와 TicketSeller에 내부 정보를 알지 못하도록 정보를 차단한다. -> 서로를 자율적인 존재로 만든다.
  • Theater에서 가지고 있던 enter메소드의 상세 로직을 캡슐화한다.
  • Theater내부 로직을 Audience와 TicketSeller에 캡슐화하여 분리함 == 책임을 이동시킴
    • 자율성이 높아졌고, 각 객체들이 밀접하게 연관된 작업만 하게됨 -> 응집도가 높아짐
    • 특정 로직을 수정할 때 함께 변경해야할 코드가 줄어듬

자율성과 결합도

• 각 객체의 자율성을 높여도 전체 설계관점에서 보면 결합도가 상승한다.
• 어떤 기능을 설계하는 방법은 여러가지일 수 있다
• 결국 설계는 트레이드 오프의 산물이다. 모두를 만족하는 설계는 불가능하다.

의인화

레베카 워프스브록은 무생물인 Bag같은 클래스도 능동적이고 자율적인 존재로 다루며 소프트웨어 객체를 설계하는 원칙을 의인화라고 부른다.