오브젝트 - 메시지와 인터페이스

[yepdi]

협력과 메시지

• 메시지는 개체 사이의 협력을 가능하게 하는 매개체다. 객체가 다른 객체에게 접근할 수 있는 유일한 방법은 메시지를 전송하는 것뿐

클라이언트 - 서버 모델

• 객체는 협력에 참여하는 동안 클라이언트와 서버의 역할을 동시에 수행
• 객체가 독립적으로 수행할 수 있는 것보다 더 큰 책임을 수행하기 위해서는 다른 객체와 협력

메시지와 메시지 전송

• 메시지 : 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단 (ex. isSatisfiedBy)
• 한 객체가 다른 객체에게 도움을 요청하는 것을 메시지 전송 또는 메시지 패싱이라고 부른다 (ex. isSatisfiedBy + condition)
• 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저를 메서드 라고 부른다

인터페이스와 설계 품질

디미터 법칙

• 협력하는 객체의 내부 구조에 대한 결합으로 인해 발생하는 설계 문제를 해결하기 위해 제안된 원칙
• 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하는 것
• 오직 하나의 도트만 사용하라

묻지말고 시켜라

• 객체이 정보를 이용하는 행동을 객체의 외부가 아닌 내부에 위치한다면 해당 객체가 책임져야 하는 어떤 행동이 객체 외부로 누수
• 인터페이스는 객체가 어떻게 하는지가 아닌 무엇을 하는지 서술

의도를 드러내는 인터페이스

• 무엇을 하는지 드러내라
  • 객체가 협력 안에 수행해야 하는 책임에 관해 고민
• 의도를 드러내는 선택자 (Intention Revealing Interface)

원칙의 함정

디미터 규칙은 하나의 도트를 강제하는 규칙이 아니다

• 객체의 내부 구조가 외부로 노출되는 경우만

결합도와 응집도의 충돌

• 묻지말고 시켜라와 디미터 법칙을 준수하는 것이 항상 긍정적인 결과로 귀결되는 것은 아니다
• 모든 상황에서 맹목적으로 위임 메서드를 추가하면 같은 퍼블릭 인터페이스 안에 어울리지 않은 오퍼레이션들이 공존

명령-쿼리 분리 원칙

• 프로시저 : 정해진 절차에 따라 내부의 상태를 변경하는 루틴의 한종류 (명령)
• 함수 : 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴의 한 종류 (쿼리)

명령-쿼리 분리와 참조 투명성

• 쿼리는 객체의 상태를 변경하지 않기 때문에 몇번이고 반복적으로 호출하더라도 상관이 없다.
  • 명령이 개입하지 않는 한 쿼리의 값은 변경되지 않기 때문에 쿼리의 결과를 예측하기 쉬워진다
• 참조 투명성 (referential transparency) 장점 수용. 버그가 적고 디버깅이 용이하며 쿼리의 순서에 따라 실행 결과가 변하지 않음

책임에 초점을 맞춰라

• 디미터 법칙 :
  • 협력이라는 컨텍스트 안에서 객체보다 메시지를 먼저 결정하면 두 객체 사이의 구조적인 결합도를 낮출 수 있음
  • 객체의 내부 구조에 대해 고민할 필요가 없어진다
• 묻지 말고 시켜라
  • 메시지를 먼저 선택하면 묻지 말고 시켜라 스타일에 따라 협력을 구조화하게 된다. 필요한 정보를 물을 필요 없이 원하는 것을 표현한 메시지를 전송
• 의도를 드러내는 인터페이스
  • 메시지를 전송하는 클라이언트 관점에서 메시지 이름을 정한다. 클라이언트가 무엇을 원하는지 그 의도가 분명하게 드러날 수 밖에 없다
• 명령-쿼리 분리 원칙
  • 객체가 단순히 어떤 일을 해야 하는지뿐만 아니라 협력 속에서 객체의 상태를 예측하고 이해하기 쉽게 만들기 위한 방법에 관해 고민
  • 예측 가능한 협력을 만들기 위해 명령과 쿼리를 분리