[객체지향의 사실과 오해] 05장 : 책임과 메시지

자율적인 책임

• 객체지향 공동체는 스스로 정한 원칙에 따라 판단하고,스스로의 의지를 기반으로 행동하는 '자율적'인 객체로구성됨
• 객체에게 할당되는 책임이 자율적 ⇒ 객체의 자율성↑
  • 자율적인 책임은 객체가 '어떻게(how)' 해야 하는가가 아니라 '무엇(what)'을 해야하는가를 설명
  • 추상적이고 포괄적인 책임 ⇒ 재사용성↑ ⇒ 객체의 자율성 ↑
    (협력에 참여하는 의도를 명확하게 설명할 수 있는 수준 안에서 추상적이어야 함)
  • 상세한 수준의 책임 명시 ⇒ 객체의 자율성↓ (∵ 객체가 선택할 수 있는 부분이 제한됨)

 

메시지와 메서드

메시지

• 객체가 다른 객체에게 전송하는 요청
• 메시지 전송 = 수신자, 메시지 이름, 인자의 조합
• 송신자는 메시지 전송을 통해서만 다른 객체의 책임을 요청할 수 있고,
  수신자는 오직 메시지 수신을 통해서만 자신의 책임을 수행할 수 있음
• 객체의 외부와 내부는 메시지를 기준으로 분리됨
  • 객체가 제공하는 메시지는 외부의 다른 객체가 볼 수 있는 공개된 영역에 속함
  • 메시지를 처리하기 위한 방법은 객체 자신의 사적 영역에 속함
• 메시지는 '어떻게' 수행될 것인지는 명시지 않고, '무엇'이 실행되기를 바라는지만 명시함
  (어떤 메서드를 선택할 것인지는 수신자가 스스로 결정)

 

메서드

• 메시지를 처리하기 위해 내부적으로 선택하는 방법
• 어떤 객체에게 메시지를 전송하면,
  수신자는 해당 메시지를 처리할 수 있는지 여부를 확인한 후, 메시지에 대응되는 특정 메서드가 실행됨
• 객체 내부의 메서드는 외부에 노출시키지 않음

 

다형성

• 서로 다른 타입에 속하는 객체들이 동일한 메시지에 대해 서로 다른 메서드를 이용해 메시지를 처리할 수 있는 메커니즘
• 서로 다른 객체들이 다형성을 만족시킨다 = 객체들이 동일한 책임을 공유한다 ⇒ 대체가능성 ⇒ 재사용성↑
• 다형성을 사용하면 송신자가 수신자의 종류를 모르더라도 메시지 전송 가능
  ⇒ 송신자에 대한 파급효과 없이 협력이 유연해짐
  ⇒ 협력의 세부적인 수행 방식을 쉽게 확장•수정 가능
  ⇒ 송신자와 수신자 간의 객체 타입에 대한 결합도↓ ⇒ 설계 유연•확장 가능•재사용 가능•수신자의 종류 캡슐화

 

묻지 말고 시켜라

• 객체는 다른 객체의 상태를 묻지 말아야 함
  (다른 객체의 상태를 묻는다는 것 = 메시지를 전송하기 전에 객체가 가져야 하는 상태에 관해 너무 많이 고민하고 있다는 증거)
• 송신자는 수신자가 어떤 객체인지 모르지만 자신이 전송한 메시지를 잘 처리할 것이라는 것을 믿고 메시지를 전송한다.
• 객체는 다른 객체의 결정에 간섭하지 말아야 하며, 모든 객체는 자신의 상태를 기반으로 스스로 결정을 내려야 한다.

 

객체 인터페이스

인터페이스

• 객체의 인터페이스는 객체가 수신할 수 있는 메시지의 목록으로 구성됨
• 인터페이스의 사용법을 익히기만 하면 내부 구조나 동작 방식을 몰라도 쉽게 대상을 조작하거나 의사를 전달할 수 있음
• 인터페이스 자체는 변경하지 않고 단순히 내부 구성이나 작동 방식만을 변경한는 것은 인터페이스 사용자에게 영향을 미치지 않음
• 대상이 변경되더라도 동일한 인터페이스를 제공하기만 하면 아무런 문제 없이 상호작용 가능

 

공용 인터페이스

• 공용 인터페이스 : 외부에서 접근 가능한 공개된 인터페이스 (외부에서 객체와 의사소통할 수 있는 고정된 경로)
• 외부 객체는 오직 공용 인터페이스에 정의된 메시지를 통해서만 객체에 접근 가능
• 객체가 어떤 메시지를 수신할 수 있느냐가 어떤 책임을 수행할 수 있느냐와 어떤 인터페이스를 가질 것인지 결정

 

인터페이스와 구현의 분리

객체지향적인 사고 방식을 이해하기 위한 세 가지 원칙

• 원칙1 : 좀 더 추상적인 인터페이스
  (지나치게 상세한 수준의 메시지를 보내는 것은 객체의 자율성을 저해)
• 원칙2 : 최소 인터페이스
  (외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 마라)
• 원칙3 : 인터페이스와 구현 간에 차이가 있다는 점 인식
  • 구현 : 객체를 구성하지만 공용 인터페이스에 포함되지 않는, 내부 구조와 작동 방식
  • 상태를 어떻게 표현할 것인가, 메서드를 구성하는 코드 자체는 외부에 노출되는 공용 인터페이스가 아니므로 객체의 구현에 해당
  • '객체의 외부와 내부를 분리하라' = '객체의 공용 인터페이스와 구현을 분리하라'

 

인터페이스와 구현의 분리 원칙

• 객체를 설계할 때 객체 외부에 노출되는 인터페이스와 객체 내부에 숨겨지는 구현을 명확하게 분리해서 고려해야 함
• 인터페이스와 구현의 분리가 중요한 이유? 소프트웨어는 항상 변경되기 때문
• 인터페이스와 구현 분리 (캡슐화)
  ⇒ 객체의 자율성↑ (∵ 외부에 영향을 주지 않고도 메서드를 자유롭게 변경 가능)

 

캡슐화

• 상태와 행위의 캡슐화 (= 데이터 캡슐화)
  • 인터페이스와 구현을 분리하기 위한 전제 조건 / 자율적인 객체를 만들기 위한 전제 조건
  • 객체가 스스로 자신의 상태를 관리
  • 상태를 변경하고 외부에 응답할 수 있는 행동을 내부에 함께 보관
• 사적인 비밀의 캡슐화
  • 외부의 객체가 자신의 내부 상태를 직접 관찰하거나 제어할 수 없도록 함
  • 의사소통 가능한 특별한 경로(공용 인터페이스)만 외부에 노출

 

책임의 자율성이 협력의 품질을 결정한다

책임의 자율성을 강조하는 이유

• 자율적인 책임은 협력을 단순하게 만든다. (책임이 적절하게 추상화된다.)
• 자율적인 책임은 객체의 외부와 내부를 명확하게 분리한다. (인터페이스와 구현이 분리된다.)
• 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
  • 변경에 의해 수정돼야 하는 범위가 좁아지고 명확해짐
  • 변경의 파급효과가 객체 내부로 캡슐화됨 ⇒ 객체 간 결합도↓
• 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다. (설계가 유연해지고 재사용성이 높아진다.)
• 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다. (책임이 자율적일수록 객체의 응집도가 높아진다.)