객체지향의 사실과 오해 갈무리

01. 협력하는 공동체

• 객체지향은 단순한 현실 세계의 모방이 아니다.
• 객체가 현실 세계의 객체와는 전혀 다르다는 사실은 객체지향 분석/설게에 관한 전통적인 관점을 송두리째 흔들기에 충분하다.

• 협력 - 역할 - 책임

  • 여러 사람들이 동일한 역할을 수행할 수 있다. 커피를 캐셔가 주문 받든, 바리스타가 주문 받든 상관없다.
  • 역할은 대체 가능성을 의미한다. 요청자 입장에서는 어떤 사람이 역할을 수행해도 문제 없다.
  • 책임을 수행하는 방법은 자율적으로 선택할 수 있다.
  • 한 사람이 동시에 여러 역할을 수행할 수 있다.
• 클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하라. 객체지향은 객체를 지향하는 것이지 클래스를 지향하는 것이 아니다.

02. 이상한 나라의 객체

• 객체란 인간이 분명하게 인지하고 구별할 수 있는 물리적인 또는 개념적인 경계를 지닌 어떤 것이다.
• 객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있다.
• 입문한 사람들이 가장 쉽게 빠지는 함정은 상태 중심으로 객체를 바라보는 것이다.

03. 타입과 추상화

• 추상화의 수준, 이익, 가치는 목적에 의존적이다.
• "현상은 복잡하다. 법칙은 단순하다. 버릴 게 무엇인지 알아내라."
• 데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는 데 사용하는 메모리 집합에 대한 메타데이터다.
• 행동이 우선이다. 객체의 타입을 결정하는 것은 객체의 행동뿐이다.
• 훌륭한 객체지향 설계는 외부에 행동만을 제공하고 데이터는 행동 뒤로 감춰야 한다. 이 원칙을 흔히 캡슐화라고 한다.

04. 역할, 책임, 협력

• 객체의 책임은 '객체가 무엇을 알고 있는가'와 '무엇을 할 수 있는가'로 구성된다.

  • 하는 것: 객체를 생성하거나 계산, 다른 객체에 행동을 시키는 것. 다른 객체의 활동을 제어
  • 아는 것: 개인적인 정보, 관련된 객체, 자신이 유도하거나 계산할 수 있는 것
• 역할은 다른 객체에 의해 대체 가능함을 의미한다.

• 설계 기법

  • 책임 주도 설계
  • 디자인 패턴
  • 테스트 주도 개발

05 책임과 메시지

• 포괄적이고 추상적인 책임을 선택한다고 해서 무조건 좋은 것은 아니다. 책임이 수행 방법을 제한할 정도로 너무 구체적인 것도 문제지만 협력의 의도를 명확하게 표현하지 못할 정도로 추상적인 것 역시 문제다.
• 메시지 중심으로 협력을 설계해야 한다.
• 객체의 행위를 결정하는 것은 객체 자체의 속성이 아니라는 점에 주목하라.
• 어떤 객체도 섬이 아니라는 말은 협력이라는 문맥 안에서 객체의 책임과 역할을 결정하라는 의미를 내포하고 있다.
• 묻지 말고 시켜라
• '어떻게'에서 '무엇'으로 전환하는 것은 객체 인터페이스의 크기를 급격하게 감소시킨다.
• 메시지를 믿어라.
• 인터페이스와 구현의 분리 원칙이 왜 중요한가? 그것은 소프트웨어는 항상 변경되기 때문이다. 수많은 객체들이 물고 물리며 돌아가는 객체지향 공동체에서 어떤 객체를 수정했을 때 어떤 객체가 영향을 받는지를 판단하는 것은 거의 곡예에 가깝다.

06 객체 지도

• 유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다. - 헤라클레이토스
• 길을 직접 알려주는 방법이 기능적이고 해결 방법 지향적인 접근법이라면 지도를 이용하는 방법은 '구조적이고 문제 지향적인 접근법'이다. 지도는 길을 찾는 데 필요한 구체적인 기능이 아니라 길을 찾을 수 있는 '구조'를 제공한다.
• 모든 소프트웨어 제품의 설계는 두 가지 측면이 존재한다. 하나는 기능측면의 설계이고, 다른 하나는 구조 측면의 설계이다. 기능 측면의 설계는 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춘다. 구조 측면의 설계는 제품의 형태가 어떠해야 하는지에 초점을 맞춘다.

07 함께 모으기

• 구현하지 않고 머릿속으로만 구상한 설계는 코드로 구현하는 단계에서 대부분 변경된다. 설계 작업은 구현을 위한 스케치를 작성하는 것이다.