🌈 Chapter 2: 객체를 활용한 테스트 주도 개발

📚 객체 망

• 객체 지향 설계는 객체 자체보다 객체 간의 의사소통에 더 집중한다.
• 객체는 메시지로 의사소통한다. 즉, 객체는 다른 객체와 메시지를 주고받으면서 반응한다.
• 객체에는 자신이 이해할 수 있는 모든 유형의 메시지를 처리하는 메서드가 있으며, 대부분 다른 객체와 의사소통을 조율하는 데 사용하는 내부 상태를 캡슐화한다.
• 객체 구성을 관리할 목적으로 작성하는 코드를 객체망의 행위에 대한 선언적(declarative) 정의라 한다. 시스템을 이런 식으로 구축하면 방법이 아니라 목적에 집중할 수 있어 시스템의 행위를 변경하기가 쉽다.

📚 값과 객체

• 시스템을 설계할 때는 값과 객체를 구부나는 것이 중요하다. 값은 변하지 않는 양이나 크기를 나타내며, 객체는 시간이 지남에 따라 상태가 변할지도 모르지만 식별자가 있는 계산 절차를 나타낸다.
• 값은 양이 고정된 불변 인스턴스다. 값은 개별적인 식별자가 없으므로 두 값 인스턴스의 상태가 같다면 사실상 동일한 셈이다. 따라서 두 값의 식별자를 비교하는 것은 적절하지 않다.
• 객체는 변경 가능한 상태를 이용해 시간의 추이에 따른 객체의 행위를 나타낸다. 타입이 똑같은 두 객체는 현재 상태가 정확히 동일하더라도 별개의 식별자를 지닌다. 이는 두 객체가 향후 어떤 메시지를 전달받느냐에 따라 상태가 달라질 수 있기 때문이다.

📚 메시지를 따르라

• 다른 객체와 쉽게 관계를 맺을 수 있게 객체를 설계하기만 한다면 고수준의 선언적 접근법이 주는 혜택을 누릴 수 있다.
• 의사소통 패턴은 객체들이 다른 객체와 상호 작용하는 방법을 과장하는 각종 규칙으로 구성돼 있다. 자바 같은 언어에서는 클래스 대신 인터페이스를 이용해 객체의 역할을 파악한다.
• 객체는 역할을 하나 이상 구현한 것이며, 역할은 관련된 책임의 집합이며, 책임은 어떤 과업을 수행하거나 정보를 알아야할 의무를 말한다. 협력은 객체나 역할의 상호 작용에 해당한다.

📚 묻지 말고 말하라

• 객체를 호출할 땐 이웃 객체가 하는 역할 측면에서 해당 객체가 무엇을 원하는지 기술하고, 호출된 객체가 그러한 바를 어떻게 실현할지 결정하게 해야 한다. 이것은 흔히 묻지 말고 말하라 스타일이나 디미터의 법칙으로 알려져 있다. 객체는 그것이 내부적으로 보유하고 있거나 메시지를 통해 확보한 정보만 가지고 의사 결정을 내려야 한다. 객체는 다른 객체를 탐색해 뭔가를 일어나게 해서는 안 된다.
• 이 스타일을 따르지 않으면 열차 전복(기차 충돌, train wreck) 코드라고 알려진 코드가 만들어진다.

// 기차 충돌 코드 예
((EditSaveCustomizer) master.getModelisable()
  .getDockablePanel()
    .getCustomizer())
      .getSaveItem().setEnabled(Boolean.FALSE.booleanValue());

• 원래 ㅗ드가 다음과 같은 코드를 의미한다는 사실을 깨달았다.

master.allowSavingOfCustomisations();

• 이렇게 하면 모든 구현 세부 사항이 메서드 호출 한 번으로 줄어든다. master를 이용하는 쪽에서는 메서드를 연이어 호출할 때 반환되는 객체의 타입에 관해 더는 알 필요가 없다. 아울러 설계 변경이 코드 기반의 구석구석 영향을 끼치는 위험도 줄었다.
• 이 원칙 덕분에 접근자 메서득 연이어 호출되도록 암시적으로 두기보다는 객체 간의 상호 작용을 명시적으로 만들고 거기에 이름을 부여하게 된다.
• 짧은 형태는 단순히 구현 방식이 아닌 코드의 목적으로 훨씬 더 명확하게 드러낸다.

📚 그래도 가끔은 물어라

• 값과 컬렉션으로부터 정보를 가져오거나 팩터리를 이용해 새 객체를 생성할 때는 묻는다.
• 예를 들어 전체 좌석을 대상으로 예약석을 고르게 배분하고만 싶다면 다음과 같은 코드로 시작할지도 모른다.

public class Train {
  private final List<Carriage> carriages [...]
  private int percentReservedBarrier = 70;

  public void reserveSeats(ReservationRequest request) {
    for(Carriage carriage: carriages) {
      if (carriage.getSeats().getPercentReserved() < percentReservedBarrier) {
        request.reserveSeatsIn(carriage);
        return;
      }

      request.cannotFindSeats();
    }
  }
}

• 여기서 Carriage의 내부 구조를 노출해서는 안 되는데, 이는 기차 안에 다양한 유형의 객차가 있기 때문만은 아닌데, 대신 스스로 답을 가늠하는 데 도움이 되는 정보를 묻기보다는 진정 답하고자 하는 질문을 던져야 한다.

public void reserveSeats(ReservationRequest request) {
  for(Carriage carriage: carriages) {
    if(carriage.hasSeatsAvailableWithin(percentReservedBarrier)) {
      request.reserveSeatsIn(carriage);
      return;
    }
  }

  request.cannotFindSeats();
}

• 질의 메서드를 추가하면 가장 적절한 객체에 행위가 자리 잡아 행위에 이해하기 쉬운 이름이 생기고 테스트하기가 쉬워진다.

📚 협력 객체의 단위 테스트

• 어떻게 객체의 내부 상태를 드러내지 않고 객체를 호출할 때 이웃 객체에 메시지를 보낼 수 있을까?
  • 한 가지 방법은 테스트에 존재하는 대상 객체의 이웃을 다른 대체물, 즉 목 객체(mock object)로 대체하는 것이다. 그렇게 하면 발생하는 이벤트에 대해 대상 객체가 가짜 이웃과 어떻게 상호 작용할지 지정할 수 있다. 이 같은 명세를 예상 구문이라 한다. 테스트가 진행되는 동안 목 객체는 자시닝 예상대로 호출됐는지 단정한다.
• 테스트를 이용하면 객체에 필요한 보조 역할을 파악하는 데 도움이 되며, 이러한 보조 역할은 자바 인터페이스로 정의돼 있고 시스템의 나머지 부분을 개발할 때 실제 구현처럼 동작한다. 이를 우리는 인터페이스 발견이라고 한다.

📚 목 객체를 활용한 TDD 지원

• 이 같은 유형의 테스트 주도 프로그래밍을 지원하려면 이웃하는 객체의 목 인스턴스를 생성하고, 해당 목 인스턴스를 어떻게 호출하고 상태를 검사하는가에 관한 예상 구문을 정의한 다음, 테스트를 할 때 스텁 형태로 동작할 필요가 있는 행위를 구현해야 한다.
• 테스트의 핵심 구조는 다음과 같다.
  • 필요한 목 객체 생성
  • 대상 객체를 포함한 실제 객체 생성
  • 대상 객체에서 목 객체가 어떻게 호출될지 예상하는 바를 기술
  • 대상 객체에서 유발 메서드를 호출
  • 결과 값이 유효하고 예상되는 메서드 호출이 모두 일어났는지 확인
• 단위 테스트는 그곳에 있는 모든 객체를 생성하고 대상 객체와 해당 객체의 협력자 사이의 상호 작용에 관한 단정을 만들어 낸다.
• 모든 테스트 의도를 명확하게 해서 테스트를 거친 기능과 보조 역할을 담당하는 기반 구조, 객체 구조를 서로 구분해야 한다.