🌈 Chapter 18: 세부 사항 처리

파생

• 파생은 어떤 개념을 식별하는 데 사용하는 위치지정자 타입으로, 코드 규모가 커짐에 따라 관련 있는 새 기능을 집어넣을 곳으로 마련해준다.

public class Item {
  public final String identifier;
  public final int stopPrice;

  public Item(String identifier, int stopPrice) {
    this.identifier = identifier;
    this.stopPrice = stopPrice;
  }

  // 이하 equals(), hashCode(), toString()
}

📚 고찰

🎈 점진적으로 만들어지는 사용자 인터페이스

• 개발 막바지 단계에서 사용자 인터페이스를 굉장히 많이 변경하는 것처럼 보인다. 하지만 정답은 "그때그때 다르지만 생각보다는 선택의 여지가 많다."이다.
• 이 예제처럼 간단한 애플리케이션의 경우, 시작할 때 사용자 인터페이스의 사용성과 응집성을 확보할 수 있도록 좀 더 세부적으로 다듬는 편이 더 타당할 것이다. 특히 테스트와 코드를 무겁게 하지 않고 유연하게 구조화하면 변화하는 요구에 대응할 수 있다는 점을 강조하고 싶기도 하다.
• 요구 사항이 바뀐다는 사실을 알고 있으며, 특히 애플리케이션을 운영 환경에 배치할 때 그러하므로 변화에 대응할 수 있어야 한다.

🎈 여전히 유효한 다른 모델링 기법

• 상태 전이 다이어그램의 좋은 점은 상태 전이 다이어그램이 테스트에 직접 대응하기 때문에 우리가 모든 가능성을 다루고 있음을 보여줄 수 있다는 것이다.
• TDD를 하고 어떻게 해야 할ㄹ지 확신이 서지 않을 때는 때때로 되돌아가서 색인 카드를 펼처보거나 상호 작용을 그려보면서 올바른 방향으로 나아가는 데 도움을 얻을 수 있다.

🎈 도메인 타입이 문자열보다 낫다

• 도메인을 명확하게 표현하는 수고를 아끼지 않았을 때 선택의 폭이 좀 더 넓어지기도 한다.
• 도메인 타입이 String뿐 아니라 컬렉션을 비롯해 다른 내장 타입까지 감싸도록 정의하는 편이 나을 때가 있다. 우리가 해야 할 일은 스스로의 충고를 잊지 않고 적용하는 것이다.