메시지와 인터페이스

  • 객체지향 프로그래밍에 대한 가장 흔한 오해는 애플리케이션이 클래스의 집합으로 구성된다는 것
  • 훌륭한 객체지향 코드를 위해서는 클래스가 아니라 객체를 지향해야함
    • 협력 안에서 객체가 수행하는 책임에 초점을 맞춰야함
    • 책임은 객체가 수신하는 메시지 기반으로 결정됨
  • 즉 객체지향에서 중요한건 클래스가 아니라 객체들이 주고 받는 메시지
  • 객체가 수신하는 메시지들이 객체의 퍼블릭 인터페이스 구성함
    • 훌륭한 퍼블릭 인터페이스를 얻기 위해서는?

1. 협력과 메시지

  • 클라이언트-서버 모델
    • 객체가 다른 객체에게 접근할수 있는 유일한 방법은 메시지를 전송하는 것
    • 두 객체 사이의 협력 관계를 설명하기 위해 사용하는 전통적인 메타포는 클라이언트-서버 모델
      • 단방향 상호작용
  • 메시지와 메시지 전송
    • 메시지
    • 메시지 전송 또는 메시지 패싱
    • 메시지 전송자, 메시지 수신자
    • 메시지는 오퍼레이션명, 인자로 구성됨
  • 메시지와 메서드
    • 메시지를 수신했을때 실제고 실행되는 함수 또는 프로시저를 메서드라함
    • 중요한 것은 코드상 동일한 이름의 변수에게 동일한 메시지를 전송하더라도 객체의 타팁에 따라 실행되는 메서드가 달라질수 있음
      • 컴파일 시점과 실행 시점의 차이
    • 메시지 전송과 메서드 호출
    • 메시지와 메서드의 구분은 메시지 전송자와 수신자가 느슨하게 결합될 수 있게 함
      • 전송자는 어떤 메시지를 전송해야하는지만 알면됨
  • 퍼블릭 인터페이스와 오퍼레이션
    • 퍼블릭 인터페이스에 포함된 메시지를 오퍼레이션이라고 부름
  • 시그니처
    • 오퍼레이션(또는 메서드)의 이름과 파라미터 목록을 합쳐 시그니처라고 부름

2. 인터페이스와 설계 품질

  • 3장에서 살펴본것 처럼 좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스라는 조건을 만족해야함
  • 디미터 법칙
    • 4장에서 설계해본 절자치향적 코드의 문제는 ReservationAgency에 전달된 Screening의 결합도가 높아서 Screening이 변경될때 마다 ReservationAgency를 수정해야한다는 것
    • 객체의 내부 구조에 대한 결합으로 인해 발생하는 설계 문제를 해결하기 위해 제안된 원칙이 디미터 법칙(Law of Demeter)
    • 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한
    • Object-Oriented Programming에서 처음 소개됨
      • 저자들은 디미터라는 프로젝트를 진행하던 도중 객체들의 협력 경로를 제한하면 결합도를 효과적으로 낮출 수 있다는 사실을 발견
    • 부끄럼 타는 코드
  • 묻지 말고 시켜라
    • 메시지 전송자는 메시지 수신자의 상태를 기반으로 결정을 내린후 메시지 수신자의 상태를 변경해서는 안됨
    • 상태를 묻는 오퍼레이션을 행동을 요청하는 오퍼레이션으로 대체함으로써 인터페이스 향상 가능
    • 인터페이스는 객체가 어떻게 하는지가 아니라 무엇을 하는지 서술해야함
  • 의도를 드러내는 인터페이스
    • 켄트벡의 Smalltalk Best Practice Patterns에서 메서드를 명명하는 두 가지 방법을 설명
      • 메서드가 작업을 어떻게 수행하는지 나타내도록 네이밍
      • 무엇을 하는지 나타내도록 네이밍
    • 어떻게 하느냐가 아니라 무엇을 하느냐에 따라 메서드의 이름을 짓는 패턴을 의도를 드러내는 선택자(Intention Reveavling Selector)라고 부름
    • 도메인 주도 설계(에릭 에반스)에서 켄트벡의 의도를 드러내는 선택자를 인터페이스(Intention Reveavling Interface) 레벨로 확장
  • 함께 모으기
    • 디미터 법칙, 묻지 말고 시켜라, 의도를 드러내는 인터페이스를 이해할 수 있는 좋은 방법 중 하나는 이런 원칙을 위한하는 코드를 살펴보는것
    • 근본적으로 디미터 법칙을 위반하는 설계는 인터페이스와 구현의 분리 원칙을 위반함
    • 디비터 법칙을 위한바면 사용하기도 어려움

3. 원칙의 함정

  • 절대적인 원칙은 없음. 모든건 트레이드 오프가 존재
    • 적절한 트레이드오프를 할수 있는 능력이 숙련자와 초보자를 구분하는 가장 중요한 포인트
  • 디미터 법칙은 하나의 도트(.)를 강제하는 규칙이 아님
  • 디미터 법칙이 항상 긍정적인 결과로 귀결되는것은 아님
    • 잘못된 책임을 떠안을 수 있음
      • 하나의 변경원칙을 가져라는 원칙 위배
      • 결과적으로 응집도가 낮아짐
  • 결합도와 응집도의 충돌
  • 로버트 마틴은 클린 코드에서 디미터 법칙 위반 여부는 묻는 대상이 객체인지, 자료 구조인지에 달려있다고 설명함
    • 객체는 내부 구조를 숨겨야함, 자료구조는 내부를 노출해야함

4. 명령-쿼리 분리 원칙

5.