객체지향의 사실과 오해 - chap5 책임과 메세지

💡 조영호님의 객체지향의 사실과 오해를 읽고 정리하였습니다

1. 자율적인 책임

• 객체가 어떤 행동을 하는 유일한 이유는 다른 객체로 부터 요청(메세지)를 받았기 때문임.
• 받은 요청을 처리하기 위해 객체가 수행하는 행동을 ‘책임’이라고함
• 책임을 수행하는데 있어 방법은 객체마다 다를 수 있고 자율적임.
  • 해당 방법을 요청하는 객체가 제한하는 것은 좋지 않음
  • 따라서, 어떻게 책임 질 것인가 보다는 무엇을 책임질 것인가가 중요함

2. 메시지와 메서드

• 메세지
  • 하나의 객체는 메세지를 전송함으로서 다른 객체에 접근함
    • 왕이 모자 장수에게 ‘증언하라’라는 메세지를 보낸는 경우
      • 모자 장수.증언하라(인자)
      • 인자에는 증언에 필요한 정보가 들어갈 수 있음(언제, 어디서 등등)
• 메서드
  • 메세지를 수신하는 객체가 메세지를 처리하기 위해 내부적으로 선택할 수 있는 방법
• 다형성
  • 동일한 메세지를 처리하는 방법은 객체마다 다를 수 있음.
  • 메세지 송신자는 수신자의 종류에 관계 없이 메세지를 전송할 수 있음
    • 메시지를 이해하는 수신자라면 송신자는 어떤 수신자와도 협력할 수 있음
    • 즉, 다형성은 수신자의 종류를 캡슐화함
  • 협력이 유연해지는 장점
  • 협력이 수행되는 방식을 확장 가능
    • 협력의 세부적인 수행 방식은 수신자가 정함
  • 협력이 수행되는 방식을 재사용 가능
    • 새로운 객체가 협력에 참여할 수 있음

3. 메시지를 따라라

• 객체지향의 핵심, 메세지
  • 클래스를 정의하는 것이 먼저가 아니라 객체의 행위와 속성을 식별하는 것이 먼저이다!
    • 클래스는 객체의 행위와 속성을 담는 틀일뿐
      • 클래스는 동적인 객체들의 특성과 행위를 정적인 텍스트로 표현하기 위해 사용하는 추상화 도구일 뿐
  • 메세지를 주고 받는 객체들 사이의 커뮤니케이션에 초점을 맞추는 것이 중요함 (협력이라는 문백을 배제하지 말것)
  • 훌륭한 객체지향설계
    • 어떤 객체가 어떤 메세지를 전송할 수 있는가?
    • 어떤 객체가 어떤 메세지를 이해할 수 있는가?
    • 위 2개의 질문에 대한 고민을 할것
• what/who 사이클
  • 어떤 행위(메세지)가 필요한지 먼저 결정하고 이 행위를 수행할 객체를 결정하는 것.
  • 메시지를 먼저 발견하면 수신가능한 메세지의 집합인 객체 인터페이스를 발견할 수 있음
• 묻지말고 시켜라
  • 송신자는 수신자가 어떤 객체인지 모르지만 자신이 전송한 메세지를 잘 처리할 것이라는 믿음을 가짐
    • 객체는 다른 객체의 결정에 간섭하지 말아야 함
    • 객체는 자신의 상태를 기반으로 스스로 결정을 내려야함
  • 객체는 다른 객체의 상태를 묻지 말아야함
    • 다른 객체의 상태를 묻는다는 것은 메세지 전송 이전에 객체가 가져야하는 상태에 대해 너무 고민하고 있다는 뜻임.
    • 메세지를 수신하는 객체가 스스로 메세지 처리 방법을 결정하게 하라
  • 객체를 자율적으로 만들고 캡슐화를 보장하고 결합도를 낮게 유지 시켜준다

4. 객체 인터페이스

• 인터페이스
  • 일반론
    • 어떤 두 사물이 마주치는 경계 지점에서 서로 상호작용할 수 있게 이어주는 방법 장치
  • 예시
    • 개발자들이 미리 약속된 어플리케이션 프로그래밍 인터페이스를 통해 다른 사람이 작성한 코드와 상호 작용함
  • 특징
    • 인터페이스의 사용법을 익히면 내부 구조나 동작방식을 모르더라도 쉽게 대상을 조작하거나 의사를 전달 할 수 있음
    • 단순 내부 구성 작동 방식 변경하는 것은 인터페이스를 사용하는 사용자에게 어떤 영향도 미치치 않음
    • 대상이 변경되더라도 동일한 인터페이스를 제공하기만 하면 아무런 문제 없이 상호작용할 수 있음
      • 하나의 자동차를 운전하기 위한 인터페이스에 익숙하다면 다른 자동차도 운전할 수 있음
• 메시지가 인터페이스를 결정
  • 객체끼리 상호작용할 수 있는 유일한 방법은 메세지 전송
  • 객체의 인터페이스는 객체가 수신할 수 있는 메세지로 구성됨
• 공용 인터페이스
  • 객체가 협력에 참여하기위해 수행하는 메시지가 객체의 공용 인터페이스의 모양을 암시함
  • 즉, 객체가 외부로부터 수신할 수 있는 메세지의 목록!

5. 인터페이스와 구현의 분리

• 객체지향적인 사고 방식을 이해하기 위한 3가지 원리
  • 좀 더 추상적인 인터페이스
    • 객체 자율성을 훼손하지 않기 위해
  • 최소 인터페이스
    • 외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 말아라
    • 협력에 필요한 메세지 이외의 불필요한 메세지를 공용 인터페이스에 포함하지 말아라
  • 인터페이스와 구현 간에 차이가 있다는 점을 인식
    • 객체의 외부와 내부를 확실하게 분리하라!
    • 구현
      • 내부 구조와 작동 방식을 가리키는 고유의 용어 (implementation)
      • 객체를 구성하지만 공용 인터페이스에 포함되지 않는 모든 것
        • 객체의 상태
        • 객체의 행동
          • 메세지 처리 방법 → 메서드
          • 메서드를 구성하는 코드자체는 외부에 노출되는 것이 아님
• 인터페이스와 구현의 분리 원칙
  • 분리가 중요한 이유
    • 소프트웨어는 항상 변하기 때문
      • 어떤 객체를 수정했을 때 어떤 객체가 영향을 받는지 판단하는 것이 어려움
      • 분리가 없고 모두 공개 되어있다면 파급효과가 모든 객체에 전달 됨
    • 결국 변경을 관리하기 위함
  • 훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체
  • 객체 설계의 핵심은 확실히 외부와 내부를 분리할 수 있는가!
  • 객체가 가지는 상태와 메서드 구현을 바꿨다고 해서 외부 객체에 영향을 주면 안됨
  • 변경될 만한 부분은 객체 내부에 숨겨야함 → 캡슐화
• 캡슐화(정보 은닉)
  • 객체 자율성을 보존하기 위해 구현을 외부에 감추는 것
  • 사용 관점
    • 상태와 행위의 캡슐화
      • 객체는 상태와 행위를 하나의 단위로 묶어 보관함
        • 데이터 캡슐화(data encapsulation)
      • 외부에 반드시 노출해야하는 행위만 공용 인터페이스를 통해 노출 시킴
    • 사적인 비밀의 캡슐화

6. 책임의 자율성이 협력의 품질을 결정

• 자율적인 책임은 협렵을 단순하게 만듬
  • 무엇에 집중하라
• 자율적인 책임은 외부와 내부를 명확하게 분리
  • 무엇이 확실하다면 어떻게는 숨길 수 있음
    • 책임을 수행하는 방법은 외부에서 볼수 없음
• 자율적인 책임의 경우 내부적인 방법을 변경하더라도 외부에 영향 미치지 않음
• 자율적인 책임은 협력의 대상을 자유롭게 선택할 수 있음
  • 책임을 수행할 수 있다면 어떤 객체든 협력에 참여할 수 있음
• 자율적인 책임일 수록 객체의 역할을 이해하기 쉬워짐
  • 여러 책임을 수해하는 객체가 어떤 역할을 하고 있는지 파악하기 쉬워짐