8장. 경계

외부 코드 사용하기

패키지/프레임워크 제공자는 적용성을 최대한 넓히려고 하고, 사용자는 자신의 요구에 집중하는 인터페이스를 바란다.

이러한 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다.

예를 들어 Map 인터페이스를 들 수 있다.

Map 객체를 사용하는 사람은 누구나 내용을 지울 수도 있고, 새로운 값을 추가할 수 있다.

즉, Map 이 반환하는 Object 를 올바른 유형으로 변환할 책임은 Map 을 사용하는 클라이언트에 있다.

이러한 Map 인스턴스를 여기저기로 넘긴다면, Map 인터페이스가 변할 경우 수정할 코드가 상당히 많아지는 문제가 생긴다. (실제로 자바 5가 제네릭스 지원하면서 Map 인터페이스가 변했었다.)

따라서 Map 과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의하자

또한 Map 인스턴스를 공개 API 의 인수로 넘기거나 반환값으로 사용하지 말자.

경계 살피고 익히기

외부 패키지의 코드에 대한 테스트는 우리의 책임이 아니다. 하지만 우리 자신을 위해 우리가 사용할 코드를 테스트 하는 것은 바람직하다.

학습 테스트

먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 방법

프로그램에서 사용하려는 방식대로 외부 API 를 호출한다. -> 통제된 환경에서 API 를 제대로 이해하는지 확인하는 방법

API 를 사용하려는 목적에 초점을 맞춘다.

학습 테스트는 공짜 이상이다

학습 테스트는 이해도를 높여주는 정확한 실험이며, 필요한 지식만 확보하는 손쉬운 방법이다.

패키지가 예상대로 도는지 검증할 수 있고, 이를 통해 새 버전이 우리 코드와 호환되지 않으면 학습 테스트가 이 사실을 곧바로 밝혀낸다.

이러한 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다.

아직 존재하지 않는 코드를 사용하기

경계와 관련해 또 다른 유형은 아는 코드와 모르는 코드를 분리하는 경계다.

우리가 바라는 인터페이스를 구현하면 우리가 인터페이스를 전적으로 통제한다는 장점이 생긴다.

또한 코드 가독성도 높아지고 코드 의도도 분명해진다.

우리가 사용할 API 가 정의되고 나면, 어댑터를 구현해 우리쪽 인터페이스와 사용할 API 사이에 간극을 메워준다.

그렇게 되면 API 사용을 캡슐화해 API 가 바뀌게 될 경우 수정해야 하는 코드를 한 곳으로 모을 수 있다.

깨끗한 경계

경계에 위치하는 코드는 깔끔하게 분리하고, 기대치를 정의하는 테스트 케이스도 작성한다.

우리 쪽 코드에서 외부 패키지를 세세하게 알아야 할 필요가 없다. 그러한 통제 불가능한 외부 패키지에 의존하는 대신, 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.

따라서, 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자

새로운 클래스로 경계를 감싸거나, 아니면 어댑터 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자.

정리

이번 장에서 저자가 말하려고 하는 내용을 3가지로 정리할 수 있는 것 같다.

1. Map 과 같은 경계 인터페이스는 클래스 밖으로 노출하지 말고, API 인수나 반환값으로도 사용하지 말자.

2. 외부 패키지는 어댑터나 새로운 클래스 등으로 감싸서 우리 입맛에 맞는 자체 인터페이스를 구축하자.

3. 학습 테스트를 통해 외부 API 에 대해 지식을 얻고, 변경이 일어날 경우 기존 코드와의 호환성을 확인하자. -> 그러면 새 버전이 나와도 이전하기 쉽다.