외부 코드 사용하기
인터페이스 제공자와 인터페이스 사용자 사이에는 특유의 경계가 존재한다.
제공자는 사용성을 높이기 위해 많은 영역에서 지원하려고 하고,
사용자는 본인이 사용하는 쪽의 특화된 기능을 원하기 때문이다.
한 가지 예로 Map 을 보면 유용성이 높지만, 그만큼 위험하기도 하다.
여러 유형의 객체를 지원하지만, 오용의 가능성도 높기 때문.
그렇기에 경계 인터페이스를 여기저기 넘기지 않고,
Map 과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.
경계 살피고 익히기
외부 코드를 익히기는 어렵고, 통합하기도 어렵다.
둘을 동시에 하려면 더 어렵다.
그렇기에 우리쪽 코드를 먼저 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 것을 학습 테스트 라고 하고,
이 학습 테스트는 통제된 환경에서 API를 제대로 이애하는지 확인하는 셈이다.
학습 테스트는 API 를 사용하는 목적에 초점이 있다.
학습 테스트는 공짜 이상이다
학습 테스트는 투자하는 노력보다 얻는 성과가 더 크다.
실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다.
이런 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다.
그렇지 않다면 낡은 버전을 필요 이상으로 오랫동안 사용하려는 유혹에 빠지기 쉽다.
아직 존재하지 않는 코드를 사용하기
경계와 관련해 또 다른 유형은 아는 코드와 모르는 코드를 분리하는 경계다.
초반에는 경계와 먼 부분부터 구현을 시작하여, 점차 만날 지점에서는 인터페이스를 구현하여 다른 곳과의 경계 부분에 adapter 패턴을 사용하여 붙인다.
깨끗한 경계
소프트웨어 설계가 우수하다면 변경하는데 많은 투자와 재작업이 필요하지 않다.
엄청난 시간과 노력과 재작업을 요구하지 않는다.
경계에 위치하는 코드는 깔끔히 분리한다. 또한 기대치를 정의하는 테스트 케이스도 작성한다.
통제가 불가능한 외부 패키지에 의존하는 것보다 통제가 가능한 우리 코드에 의존하는 편이 좋다.
자칫하면 외부 코드에 휘둘리기 때문이다. 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.
새로운 클래스로 경계를 감싸거나, adapter 패턴을 사용해 인터페이스를 변환하자.
덧붙이면...?
이번 챕터에서는 외부 라이브러리 혹은 외부 API 등과 연결을 할 때, 어떻게 해야할지에 대해서 나와있다.
그리고 학습테스트(유닛테스트) 가 중요하다는 사실을 말하는 장이기도 하다.
이 책을 읽다보면 마틴 파울러의 리팩토링 책과 내용이 겹친다고 느껴지는 부분이 많다. (마치 시중에 있는 많은 자기계발서 와 비슷한..?)
그만큼 중요하지만 익숙해지지 않으면 힘든 것 같다. 나만해도 머리로는 해야지 하면서도 행동은 글쎄...? 니까
책을 읽으면서 중간에 낡은 버전을 필요 이상으로 오랫동안 사용하려는 유혹에 빠지기 쉽다 라는 부분이 있다.
이전에 이런 경험이 있긴 하다. 타 라이브러리가 핵심 코어로 된 패키지 프로젝트가 있었다. 뭐 여기까지는 좋다. 그럴 수 있으니까.
하지만, 그 패키지에 테스트 케이스는 존재하지 않았고, 물론 리팩토링도 없었다.
그러다보니 시간이 지나면서 군데군데 요구사항 변경에 의한 땜빵만 늘어났고, 결국은 버리고 싶어도 버릴 수 없는 애물단지 같은 느낌이었다. (왜냐고? 일단, 돌아는 가니까 팔아야지!)
이런 부분을 생각하면 정말 아쉽긴 하다. 하지만, 지금 그 때로 돌아간다고 해도 단위테스트를 만들고 그럴 수 있을 것 같진 않다.
하루살이란 느낌이 강했으니까...
옆길로 좀 새긴 했지만... 이번 장에서는 테스트를 통한 경계에 대해 말하기도 하지만, map 과 vo 에 대해서도 생각해볼 수 있는 좋은 장이었다.