ch4-3-유연한-인터페이스-만들기

4.3.7 새로운 객체를 찾아내기 위해 메시지를 사용하기

앞에서 봤던 다이어그램을 개선해보자.

위 문제의 유스케이스는 여행객은, 여행길을 선택하기 위해, 정해진 날짜에 자전거를 빌리고, 여행길 목록을 보고 싶어함

첫번쨰 그림은

• 많은 책임을 가진 Trip

두번째 그림은

• 빌릴 수 있는 자전거를 찾아야하는 책임을 Trip에서 Bicycle로 옮겼지만

  • customer는 여행에 대해 너무 많이 알고, 책임을 가짐

  • 너무 많은 맥락 속에 갇힘

위 2가지 디자인 모두 재사용 어려움, 변경도 어려움, 단일 책임 원칙 위반

다시 정리해보자.

• Customer는 suitable_trips 메서드를 전송하는 것은 타당

• 문제는 송신자가 아닌 수신자에게 있음

Customer, Trip, Bicycle이 교차하는 지점에서 여행을 찾아 줄 객체가 필요. suitable_trips 메서드는 이 객체의 퍼블릭 인터페이스의 한 부분을 차지할거임

TripFinder는

• 여행을 찾아내는 방법을 알고

• suitable_trips 메시지에 답하기 위해 가능한 모든 방법을 시도하는 것이 이 클래스의 역할

• 내부적으로 지저분하고 언제 변경될지 모르는 세부 구현사항을 숨기고 있을지라도

• 이 클래스는 안정적인 퍼블릭 인터페이스를 제공

• suitable_trips 메서드를 TripFinder로 옮겼기 때문에

• 다른 객체들도 이 행동에 접근 가능

애플리케이션의 특징을 드러내는 것은 인터페이스 테스트보다 다른 어떤 코드 보다 인터페이스가 중요

4.4.1 명시적인 인터페이스 만드릭

퍼블릭 인터페이스의 메서드

• 일반적인 의미, 엄밀하고 명시적으로 규정되야 함

• 어떻게 보다는 어떤 것에 대해 말해야함

• 예측할 수 있는 한도에서나마 바뀌지 않을 이름 짓기

• 추가적인 인자를 해시로 받기

4.4.4 최소한의 맥락 속에 위치시키기

퍼블릭 인터페이스를 구성할 경우 다른 객체와 연계되어 있는 맥락을 최소화 하자

앞의 예제에서 봤듯이

• Mechanic 클래스 안에 새로운 메서드를 정의할 수도 있고

• Mechanic 클래스를 감싸는 새로운 클래스를 만들어서 Mechanic 대신 사용할 수도 있고

• 우리가 만든 클래스 안에 Mechanic을 호출하는 부분을 감싸는 작은 메서드를 만들수도 있음

4.6 요약

객체 지향 App은 객체들이 서로 주고받는 메시지를 통해 정의됨 이 메세지들은 퍼블릭 인터페이스를 타고 흐름

메시지에 집중하면, 예전에는 미처 파악하지 못한 객체를 찾을 수 있음 메시지가 '수신자가 어떻게 행동해야 하는지'를 알려주기보다 수신자를 믿고 전송자가 원하는 것(무엇)을 말한다면, 객체는 자연스럽게 퍼블릭 인터페이스를 발전시키기 됨121221