외부 코드를 우리 코드에 깔끔하게 통합하자.
외부 코드 사용하기
- 인터페이스 제공자: 적용성을 최대한 넓히려 애쓴다.
- 인터페이스 사용자: 자신의 요구에 집중하는 인터페이스를 바란다.
Map 인터페이스는 사용자에게 필요하지 않은 기능까지 제공한다. (ex. clear 메소드)
Map<String, Sensor> 인스턴스를 여기저기로 넘기면, Map 인터페이스가 변경되었을 때 수정할 코드가 많아진다.
public class Sensors {
private Map sensors = new Hashmap();
public Sensor getById(String id) {
return (Sensor) sensors.get(id);
}
}위와 같이 캡슐화해서 사용하면 Map 인터페이스가 변경되더라도 나머지 프로그램에는 영향을 미치지 않는다.
Map과 같은 경계 인터페이스를 항상 캡슐화하라는 의미가 아니고,
이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의하라는 의미다.
인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다.
경계 살피고 익히기
곧바로 우리쪽 코드를 작성해 외부 코드를 호출하는 대신,
먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히자. => 학습 테스트(테스트 주도 개발, 짐 뉴커크)
log4j 익히기
의의를 모르겠다.
학습 테스트의 예를 보여주는 듯한데, TDD의 개념을 잘 몰라서 그런지 이해가 잘 가지 않는다.
=> 학습 테스트를 이용하여 외부 패키지를 배우는 방법을 보여주고 있다.
학습 테스트는 공짜 이상이다
패키지 새 버전이 나온다면 학습 테스트를 돌려 차이가 있는지 확인한다.
=> 새 버전이 우리 코드와 호환되지 않으면 학습 테스트가 이 사실을 곧바로 밝혀낸다.
아직 존재하지 않는 코드를 사용하기
모르는 부분의 구현은 미뤄두고, 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제할 수 있고, 코드 가독성은 높아지며, 코드 의도도 분명해진다.
ADAPTER 패턴(GOF의 디자인 패턴): API 사용을 캡슐화해 API가 바뀔 때 수정할 코드를 한 곳에 모은다.
깨끗한 경계
- 경계에 위치하는 코드는 분리한다.
- 기대치를 정의하는 테스트 케이스를 작성한다.
- 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.
- 새로운 클래스로 경계를 감싼다.
- ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환한다.
얻는 효과
- 코드 가독성이 높아진다.
- 경계 인터페이스를 사용하는 일관성이 높아진다.
- 외부 패키지가 변했을 때 변경할 코드가 줄어든다.
