06 메시지와 인터페이스

훌륭한 객체지향을 위해서는 클래스가 아닌 객체를 지향해야 한다. 협력 안에서 객체가 수행하는 책임에 초점을 맞춰야 한다.

책임은 객체가 수신할 수 있는 메시지의 기반이 된다.

객체지향 애플리케이션의 가장 중요한 재료는 객체들이 주고받는 메시지다.

매시지들이 객체의 퍼블리 인터페이스를 구성한다.

1. 협력과 메시지

클라이언트-서버 모델

• 클라이언트: 메시지를 전송하는 객체
  Screening은 '가격을 계산하라' 메시지를 전송함으로써 도움 요청
  Movie는 '할인 요금을 계산하라' 메시지를 전송함으로써 도움 요청
• 서버: 메시지를 수신하는 객체
  Movie는 가격을 계산하는 서비스를 제공함으로써 메시지에 응답
  DiscountPolicy는 할인 요금을 계산하는 서비스를 제공함으로써 메시지에 응답
• 협력: 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용

객체는 협력에 참여하는 동안 클라이언트와 서버의 역할을 동시에 수행하는 것이 일반적이다.

객체는 수신하는 메시지의 집합과 외부의 객체에게 전송하는 메시지의 집합으로 구성된다.

메시지와 메시지 전송 & 메시지와 메서드

• 메시지: 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단 (오퍼레이션명 + 인자)
• 메시지 전송/패싱: 한 객체가 다른 객체에게 도움을 요청하는 것 (메시지 + 메시지 수신자)
• 메시지 전송자(클라이언트): 메시지를 전송하는 객체
• 메시지 수신자(서버): 메시지를 수신하는 객체
• 메서드: 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저

객체는 메시지와 메서드라는 두 가지 서로 다른 개념을 실행 시점에 연결해야 하기 때문에,

컴파일 시점과 실행 시점의 의미가 달라질 수 있다.

객체지향은 메시지 전송과 메서드 호출을 명확하게 구분한다.

 

전송자와 수신자는 서로에 대한 상세한 정보를 알지 못한 채 메시지라는 끈을 통해서만 연결된다.

실행 시점에 메시지와 메서드를 바인딩하는 메커니즘은 결합도를 낮춘다.

• 퍼블릭 인터페이스: 객체가 의사소통을 위해 외부에 공개하는 메시지의 집합
• 오퍼레이션: 퍼블릭 인터페이스에 포함된 메시지. 수행 가능한 어떤 행동에 대한 추상화
  DiscountCondition 인터페이스에 정의된 isSatisfiedBy
• 메서드: 메시지를 수신했을 때 실제로 실행되는 코드
  SequenceCondition과 PeriodCondition의 두 메서드

오퍼레이션이란 실행하기 위해 객체가 호출될 수 있는 변환이나 정의에 관한 명세다.

인터페이스의 각 요소는 오퍼레이션이다. 오퍼레이션은 구현이 아닌 추상화다.

메서드가 오퍼레이션에 대한 구현이다.

 

객체가 메시지를 전송하면, 런타임 시스템은 메시지 전송을 오퍼레이션 호출로 해석하고,

수신한 객체의 실제 타입을 기반으로 적절한 메서드를 찾아 실행한다.

메서드 호출보다는 오퍼레이션 호출이 더 적절한 표현이다.

• 시그니처: 오퍼레이션(메서드)의 이름과 파라미터 목록
• 오퍼레이션: 실행 코드 없이 시그니처만 정의
• 메서드: 시그니처 + 구현
• 다형성: 동일한 오퍼레이션 호출에 대해 서로 다른 메서드들이 실행되는 것

메시지를 수신하면 오퍼레이션의 시그니처와 동일한 메서드가 실행된다.

다형성을 통해 하나의 오퍼레이션에 대해 다양한 메서드를 구현하게 된다.

메시지가 객체의 퍼블릭 인터페이스와 그 안에 포함될 오퍼레이션을 결정한다.

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

좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스라는 조건을 만족해야 한다.

책임 주도 설계는 메시지를 먼저 선택함으로써 협력과 무관한 오퍼레이션이 인터페이스에 스며드는 것을 방지한다.

퍼블릭 인터페이스의 품질에 영향을 미치는 원칙과 기법에 관해 살펴보자.

디미터 법칙: 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라

할인 가능 여부를 체크하는 코드를 보자.

public Reservation reserve(Screening screening, Customer customer, int audienceCount) {
        Movie movie = screening.getMovie();

        boolean discountable = false;
        for(DiscountCondition condition : movie.getDiscountConditions()) {
            if (condition.getType() == DiscountConditionType.PERIOD) {
                discountable = screening.getWhenScreened().getDayOfWeek().equals(condition.getDayOfWeek()) &&
                        condition.getStartTime().compareTo(screening.getWhenScreened().toLocalTime()) <= 0 &&
                        condition.getEndTime().compareTo(screening.getWhenScreened().toLocalTime()) >= 0;
            } else {
                discountable = condition.getSequence() == screening.getSequence();
            }

            if (discountable) {
                break;
            }
        }
  }

가장 큰 문제는 ReservationAgency와 Screening 사이의 결합도가 너무 높다는 것이다.

ReservationAgency가 Screening뿐만 아니라 Movie와 DiscountCondition에도 직접 접근하기 때문이다.

 

디미터 법칙을 따르기 위해서는 클래스가 특정한 조건을 만족하는 대상에게만 메시지를 전송하도록 프로그래밍해야 한다.

클래스 C와 C에 구현된 메서드 M에 대해서, M이 메세지를 전송할 수 있는 객체는 다음에 서술된 클래스의 인스턴스여야 한다.

• M의 인자로 전달된 클래스(C 자체를 포함)
• C의 인스턴스 변수의 클래스

클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 해야 한다

• this 객체
• 메서드의 매개변수
• this의 속성
• this의 속성인 컬렉션의 요소
• 메서드 내에서 생성된 지역 객체

결합도 문제를 해결한 ReservationAgency의 코드를 보자.

class ReservationAgency {
  public reserve(screening: Screening, customer: Customer, audienceCount: number): Reservation {
    const fee: Money = screening.calculateFee(audienceCount);
    return new Reservation(customer, screening, fee, audienceCount);
  }
}

ReservationAgency는 인자로 전달된 Screening 인스턴스에게만 메시지를 전송한다.

 

디미터 법칙을 따르면 shy code를 작성할 수 있다.

shy code: 불필요한 어떤 것도 다른 객체에게 보여주지 않으며, 다른 객체의 구현에 의존하지 않는 코드

// 디미터 법칙 위반
screening.getMovie().getDiscountConditions();
// 개선 코드
screening.calculateFee(audienceCount);

클래스의 내부 구현이 외부로 노출됐을 때 나타나는 전형적인 형태로 기차 충돌이 있다.

전송자가 수신자의 내부 구조에 대해 물어보고 받환받은 요소에 대해 연쇄적으로 메시지를 전송한다.

객체의 내부 구조를 묻는 메시지보다 수신자가 무언가를 시키는 메시지가 더 좋다.

묻지 말고 시켜라: 객체의 상태에 관해 묻지말고 원하는 것을 시켜라

전송자가 수신자의 상태를 기반으로 결정을 내린 후 수신자의 상태를 바꿔서는 안 된다.

밀접하게 연관된 정보와 행동을 함께 가지는 객체를 만들어야 한다.

이 원칙에 따르면 자연스럽게 정보 전문가에게 책임을 할당하게 된다.

 

내부 상태를 묻는 오퍼레이션은 행동을 요청하는 오퍼레이션으로 대체함으로써 인터페이스를 향상시키자.

 

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

훌륭한 인터페이스를 위해서는 객체가 어떻게 작업을 수행하는지를 노출해서는 안 된다.

인터페이스는 어떻게가 아니라 무엇을 하는지를 서술해야 한다.

 

나쁜 스타일: 메서드가 작업을 어떻게 수행하는지를 나타내도록 명명

class PeriodCondition {
  public isSatisfiedByPeriod(screening: Screening): boolean {}
}
class SequenceCondition {
  public isSatisfiedBySequence(screening: Screening): boolean {}
}

• 메서드에 대해 제대로 커뮤니케이션하지 못한다.
  메서드의 이름이 다르기 때문에 내부 구현을 모르면 두 메서드가 동일한 작업을 수행한다는 사실을 알기 어렵다.
• 메서드 수준에서 캡슐화를 위반한다. 클라이언트가 협력하는 객체의 종류를 알도록 강요한다.

좋은 스타일: 메서드가 무엇을 수행하는지를 나타내도록 명명

interface DiscountCondition {
  isSatisfiedBy(screening: Screening): boolean;
}

class PeriodCondition implements DiscountCondition {
  public isSatisfiedBy(screening: Screening): boolean {}
}
class SequenceCondition implements DiscountCondition {
  public isSatisfiedBy(screening: Screening): boolean {}
}

메서드가 무엇을 하느냐에 초점을 맞추면 클라이언트의 관점에서 동일한 작업을 수행하는 경우 하나의 타입 계층으로 묶을 수 있게 된다.

• 의도를 드러내는 선택자: 무엇을 하느냐에 따라 메서드의 이름을 짓는 패턴
• 의도를 드러내는 인터페이스: 의도를 드러내는 선택자를 인퍼테이스 레벨로 확장한 패턴
  구현과 관련된 모든 정보를 캡슐화하고 객체의 퍼블릭 인터페이스에는 협력과 관련된 의도만을 표현해야 함

객체에게 묻지 말고 시키돼 구현 방법이 아닌 클라이언트의 의도를 드러내야 한다.

정리하기 

디미터 법칙을 위반하는 티켓 판매 도메인

public class Theater {
    private TicketSeller ticketSeller;

    public Theater(TicketSeller ticketSeller) {
        this.ticketSeller = ticketSeller;
    }

    public void enter(Audience audience) {
        if (audience.getBag().hasInvitation()) {
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().setTicket(ticket);
        } else {
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            ticketSeller.getTicketOffice().plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
    }
}

Theater는 Audience의 퍼블릭 인터페이스뿐만 아니라 내부 구조에 대해서도 결합된다.

 

디미터 법칙을 위반하는 설계는 인터페이스와 구현의 분리 원칙을 위반한다.

디미터 법칙을 위반한 코드는 결합도가 높고, 요구사항 변경에 취약하고, 사용하기 어렵다.

 

Audience가 퍼블릭 인터페이스에 getBag을 포함시키는 순간 객체의 구현이 퍼블릭 인터페이스를 통해 외부로 새어나갔다.

Audience와 TicketSeller의 내부 구조를 묻는 대신 Audience와 TicketSeller가 직접 자신의 책임을 수행하도록 시키자.

묻지 말고 시켜라 

Audience와 TicketSeller는 묻지 말고 시켜라 스타일을 따르는 퍼블릭 인터페이스를 가져야 한다.

Theater가 TicketSeller에게 자신이 원하는 일(Audience가 Ticket을 가지도록 만드는 것)을 시키도록 수정하자.

 

TicketSeller에 setTicket을 추가하고 enter 메서드의 로직을 옮겨오자.

class TicketSeller {
  private ticketOffice: TicketOffice;

  public setTicket(audience: Audience): void {
    const ticket: Ticket = this.ticketOffice.getTicket();
    if (!audience.getBag().hasInvitation()) {
      audience.getBag().minusAmount(ticket.getFee());
      this.ticketOffice.plusAmount(ticket.getFee());
    }
    audience.getBag().setTicket(ticket);
  }
}

 Theater는 속성으로 포함하고 있는 TicketSeller에게만 메시지를 전송해야 한다.          

class Theater {

  public enter(audience: Audience): void {
    this.ticketSeller.setTicket(audience);
  }
}

Audience에 setTicket을 추가하고 스스로 티켓을 가지도록 하자.

class Audience {
  private bag: Bag;

  public setTicket(ticket: Ticket): number {
    this.bag.setTicket(ticket);
    if (this.bag.hasInvitation()) {
      return 0;
    } else {
      this.bag.minusAmount(ticket.getFee());
      return ticket.getFee();
    }
  }
}

TicketSeller는 속성으로 포함하고 있는 TicketOffice와 인자로 전달된 Audience에게만 메시지를 전송해야 한다.

class TicketSeller {
  private ticketOffice: TicketOffice;

  public setTicket(audience: Audience): void {
    this.ticketOffice.plusAmount(
      audience.setTicket(this.ticketOffice.getTicket())
    );
  }
}

Audience가 Bag에게 원하는 일을 시키기 전에 hasInvitation을 사용하고 있다. 디미터 법칙을 위반하고 있다.

Audience의 setTicket을 Bag으로 옮기자.

class Bag {
  private amount: number;
  private invitation: Invitation | null;
  private ticket: Ticket | null;

  private hasInvitation(): boolean {
    return this.invitation !== null;
  }

  public setTicket(ticket: Ticket): number {
    this.ticket = ticket;
    if (this.hasInvitation()) {
      return 0;
    } else {
      this.minusAmount(ticket.getFee());
      return ticket.getFee();
    }
  }

  private minusAmount(amount: number): void {
    this.amount -= amount;
  }
}

class Audience {
  private bag: Bag;

  public setTicket(ticket: Ticket): number {
    return this.bag.setTicket(ticket);
  }
}

스타일을 따르고 디미터 법칙을 준수하는 Audience를 얻을 수 있다.

public class Audience {

    public Long setTicket(Ticket ticket) {
        return bag.setTicket(ticket);
    }
}

Audience는 자신의 상태를 스스로 관리하고 결정하는 자율적인 존재가 됐다.

인터페이스에 의도를 드러내자

디미터 법칙과 묻지 말고 시켜라 원칙을 따르는 인터페이스를 얻었다면,

인터페이스가 클라이언트의 의도를 올바르게 반영했는지 확인해야 한다.

 

TicketSeller, Audience, Bag 각각의 입장에서 setTicket이라는 이름은 협력하는 클라이언트의 의도를 명확히 드러내지 못한다. 

• Theater가 TicketSeller에게 원했던 것은 Audience에게 티켓을 판매하는 것이다. (setTicket -> sellTo)
• TicketSeller가 Audience에게 원했던 것은 Audience가 티켓을 사는 것이다. (setTicket -> buy)
• Audience가 Bag에게 원했던 것은 티켓을 보관하는 것이다. (setTicket -> hold)

오퍼레이션의 이름은 협력이라는 문맥을 반영해야 한다. 객체 자신이 아닌 클라이언트의 의도를 표현해야 한다.

• 디미터 법칙: 캡슐화를 위반하는 메시지가 인터페이스에 포함되지 않도록 제한
• 묻지 말고 시켜라: 디미터 법칙을 준수하는 협력을 만들기 위한 스타일 제시
• 의도를 드러내는 인터페이스: 객체의 퍼블릭 인터페이스에 어떤 이름이 드러나야 하는지에 대한 지침 제공

3. 원칙의 함정

 원칙에는 예외가 넘쳐난다. 설계는 트레이드오프의 산물이다.

원칙을 아는 것보다 더 중요한 것은 언제 원칙이 유용하고 유용하지 않은지를 판단하는 것이다.                                           

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

디미터 법칙은 "오직 하나의 도트만을 사용하라"라는 말로 요약되기도 한다.

그러나 디미터 법칙은 결합도과 관련된 것이며, 객체의 내부 구조가 외부로 노출되는 경우로 한정된다.

기차 충돌처럼 보이는 코드라도 객체의 내부 구현에 대한 어떤 정보도 외부로 노출하지 않는다면 디미터 법칙을 주수한 것이다.                                                                                                                                                                                              

결합도와 응집도의 충돌

우리는 캡슐화를 위반하는 코드를 개선하기 위해 객체가 스스로 행동할 수 있도록 객체에게 위임 메서드를 추가했다.

위임 메서드를 통해 객체의 내부 구조를 감추는 것은 결합도를 낮추고 응집도를 높이는 효과적인 방법이다.

 

그러나 맹목적으로 위임 메서드를 추가하면 같은 퍼블릭 인터페이스 안에 어울리지 않는 오퍼레이션들이 공존하게 된다.

결과적으로 상관 없는 책임들을 한꺼번에 떠안게 되기 때문에 응집도가 낮아진다.

 

클래스는 하나의 변경 원인만을 가져야 한다.

디미터 법칙과 묻지 말고 시켜라 원칙을 무작정 따르면 응집도는 낮아질 것이다.

 

PeriodCondition은 screening에게 상영 시작 시간을 물어서 할인 여부를 결정한다.

Screening의 내부 상태를 가져와서 사용하기 때문에 캡슐화를 위반한 것으로 보일 수 있다.

할인 여부를 판단하는 로직을 Screening으로 옮기면 묻지 말고 시켜라 스타일을 준수하는 것으로 보일 수 있지만,

이렇게 하면 Screening이 기간에 따른 할인 조건을 판단하는 책임을 떠안게 된다. 이는 본질적인 책임이 아니다.

 

묻는 것 외에는 다른 방법이 존재하지 않는 경우도 있다. 물으려는 객체가 정말로 데이터인 경우도 있다.

객체는 내부 구조를 숨겨야 하므로 디미터 법칙을 따르는 것이 좋지만,

자료 구조라면 당연히 내부를 노출해야 하므로 디미터 법칙을 적용할 필요가 없다.

 

04 명령-쿼리 분리 원칙

가끔씩은 필요에 따라 물어야 한다는 사실에 납득했다면 명령-쿼리 분리 원칙을 알아두면 도움이 될 것이다. 

루틴:어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈 

루틴은 다시 프로시저와 함수로 구분할 수 있다. 

명령(Command)과 쿼리(Query)는 객체의 인터페이스 측면에서 프로시저와 함수를 부르는 또 다른 이름이다. 

객체의 상태를 수정하는 오퍼레이션을 명령이라 부르고 객체와 관련된 정보를 반환하는 오퍼레이션을 쿼리라고 부른다. 

반복 일정의 명령과 쿼리 분리하기 

이벤트: 특정 일자에 실제로 발생하는 사건을 의미한다. 

반복 일정: 일주일 단위로 돌아오는 특정 시간 간격에 발생하는 사건 전체를 포괄적으로 지칭하는 용어 

 

이벤트라는 개념은 Event 클래스로 구현된다. Event 클래스는 이벤트 주제(subject), 시작 일시(from), 소요 시간(duration)을 인스턴스 변수로 포함하는 간단한 클래스다.

public class Event {
    private String subject;
    private LocalDateTime from;
    private Duration duration;

    public Event(String subject, LocalDateTime from, Duration duration) {
        this.subject = subject;
        this.from = from;
        this.duration = duration;
    }
}

"2019년 5월 8일 수요일 10시 30분부터 11시까지 열리는 회의"를 표현하는 Event의 인스턴스는 다음과 같이 생성할 수 있다.

 Event meeting = new Event("회의", LocalDateTime.of(2019,5,8,10,30),
                Duration.ofMinutes(30));

"반복 일정"은 RecurringSchedule 클래스로 구현한다. 앞에서 설명한 것처럼 RecurringSchedule은 주 단위로 반복되는 일정을 정의하기 위한 클래스다. 따라서 일정의 주제(subject)와 반복될 요일(dayOfWeek), 시작 시간(from), 기간(duration)을 인스턴스 변수로 포함한다. 

public class RecurringSchedule {
    private String subject;
    private DayOfWeek dayOfWeek;
    private LocalTime from;
    private Duration duration;

    public RecurringSchedule(String subject, DayOfWeek dayOfWeek,
                             LocalTime from, Duration duration) {
        this.subject = subject;
        this.dayOfWeek = dayOfWeek;
        this.from = from;
        this.duration = duration;
    }

    public DayOfWeek getDayOfWeek() {
        return dayOfWeek;
    }

    public LocalTime getFrom() {
        return from;
    }

    public Duration getDuration() {
        return duration;
    }
}

안타깝게도 이 isSatisfied 메서드 안에 개발팀을 그토록 당혹하게 만들었던 버그가 숨겨져 있다. 다음코드를 보자.

RecurringSchedule schedule = new RecurringSchedule("회의", DayOfWeek.WEDNESDAY,
                LocalTime.of(10,30),Duration.ofMinutes(30));
        Event meeting = new Event("회의", LocalDateTime.of(2019,5,8,10,30),
                Duration.ofMinutes(30));
        assert meeting.isSatisfied(schedule) == false;
        assert  meeting.isSatisfied(schedule) == true;

동일한 Event와 동일한 RecurringSchedule을 이용해 isSatisfied를 두 번 호출했을 때 각 결과가 다른 이유는 무엇일까?

public boolean isSatisfied(RecurringSchedule schedule) {
        if (from.getDayOfWeek() != schedule.getDayOfWeek() ||
                !from.toLocalTime().equals(schedule.getFrom()) ||
                !duration.equals(schedule.getDuration())) {
            reschedule(schedule);
            return false;
        }

        return true;
    }

isSatisfied 메서드는 먼저 인자로 전달된 RecurringSchedule의 요일, 시작 시간,소요 시간이 현재 Event의 값과 동일한지 판단한다. 

하지만 false를 반환하기 전에 reschedule 메서드를 호출하고 있다는 사실에 주목하라. 안타깝게도 이 메서드는  Event 객체의 상태를 수정한다. 

public class Event {
    private void reschedule(RecurringSchedule schedule) {
        from = LocalDateTime.of(from.toLocalDate().plusDays(daysDistance(schedule)),
                schedule.getFrom());
        duration = schedule.getDuration();
    }

    private long daysDistance(RecurringSchedule schedule) {
        return schedule.getDayOfWeek().getValue() - from.getDayOfWeek().getValue();
    }
}

isSatisfied가 명령과 쿼리의 두 가지 역할을 동시에 수행하고 있었기 때문이다.