8장. 경계

모든 코드를 손수 다 만드는 경우는 드뭅니다. 대부분 외부에서 잘 만들어진 라이브러리를 사용하게 되는데, 이번장에서는 어떻게 외부 코드를 내부 코드와 깔끔하게 통합할 수 있을지 알아보겠습니다.

외부 코드 사용하기

인터페이스 제공자는 최대한 적용성을 넓히려 하고, 인터페이스 사용자는 자신의 프로그램에 핏이 딱 맞는 것을 선호합니다.

그렇기 때문에 인터페이스 사용자는 필요하지도 않은 기능들까지 포함된 인터페이스를 사용하게 됩니다.

예를 들어 Map이 그렇습니다.

Map에는 clear() 함수가 존재하기 때문에 Map에 접근 가능한 사용자는 값을 지울수 있게 됩니다.

또한 Map은 타입을 지정하지 않기 때문에 모든 요소를 추가할 수도 있습니다.

이를 위해 제네릭 타입을 사용하여 타입을 동적으로 할당할 수 있지만 여전히 불필요한 기능들이 포함되어 있는 것은 막을 수 없습니다.

Map을 여기저기 파라미터로 넘겨 받아 처리를 한다면 추후 Map 인터페이스가 변경되면 굉장히 많은 코드를 손봐야 합니다.

Map같은 인터페이스가 변경 될리 없다고 생각할지 모르겠지만 이미 Java 5에서 제네릭을 추가하며 많은 변경이 있었던 이력이 있습니다.

이렇듯 어떤 것이든 외부에 의존하는 코드는 좋지 않습니다.

외부 패키지 테스트가 우리의 책임은 아닙니다. 하지만 외부 라이브러리를 사용하여 개발을 하다가 로직이 돌아가지 않는 것은 우리 책임입니다.

외부 라이브러리를 익히고 내부 코드와 통합하기는 굉장히 힘든일입니다.

그렇기에 외부 라이브러리를 익힐 겸 해당 라이브러리에 대한 학습 테스트를 작성하는 것이 좋습니다.

학습 테스트란 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 것을 말합니다.

학습 테스트를 작성하게 되면 라이브러리를 익히는 것 뿐만 아니라 추후 라이브러리가 업데이트 되었을 때 기존과 다르게 동작하는지 쉽게 확인할 수 있습니다.

이렇게 되면 새로운 버전으로 이전하기 쉬워지기 때문에 레거시를 오랫동안 유지하지 않아도됩니다.

클라이언트를 개발한다고 가정하면 서버에서 API를 받아 화면을 구성하게 됩니다.

이때 아직 API 스펙이 정해지지 않았다면 어떻게 할 것인가요? 마냥 API 스펙이 다 나올 동안 기다릴 건가요?

화면에 필요한 값들을 임시로 생각을 해서 우선 개발을 한 뒤, 추후 API 스펙에 맞게 변경을 하면 됩니다.

하지만 기존에 작성했던 변수명 등을 나중에 모두 API 스펙에 맞게 변경 하는것은 좋은 생각은 아닙니다. 추후 API 스펙이 또 변경되면 또 그에 맞게 모든 변수명을 수정할 수는 없으니까요.

이럴 때 우리에게 필요한 인터페이스를 만들어 사용하다가, API 스펙이 나오면 API 스펙을 어댑터 패턴을 사용하여 우리 인터페이스에 맞게 구현하면 됩니다.

그럼 우리는 우리가 만든 인터페이스에만 의존한 채 개발을 할 수 있습니다.

경꼐에 위치하는 코드는 깔끔히 분리해야합니다.

모든 것을 인터페이스로 만들어 사용하는 것은 이론적으로는 완벽하나, 실질적으로는 너무 과합니다.

그렇기 때문에 변경 가능성이 많은 요소들은 인터페이스를 만들고 변경이 비교적 적거나 거의 없을 요소들은 클래스만 만들어 사용하게 됩니다.

즉, 인프라 적인 요소는 반드시 인터페이스를 만들어야하며 컨트롤러 같이 확장 가능성이 거의 없는 요소는 일반적인 클래스로 만들어 사용해도 됩니다.