> For the complete documentation index, see [llms.txt](https://real-dev.gitbook.io/real-library/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://real-dev.gitbook.io/real-library/clean-code/readme/8..md).

# 8. 경계

본 챕터에서 논하는 경계는 `외부 API, 라이브러리, 패키지와 내부 소스 코드 간의 경계`를 의미하는 듯 하다.

<br>

#### 외부 코드 사용하기

* 인터페이스 제공자와 사용자 간엔 미묘한 경계가 존재한다. 예를 들어 Map 인터페이스는 사용자가 요구하는 것보다 다양한 기능을 제공하며, 이는 사용자가 예상못한 용례를 허용한다.
* 모든 Map 사용법마다 그럴 필요는 전혀 없지만, 필요하다면 별도의 클래스로 래핑하여 사용하면 사용례를 제한할 수 있다.

<br>

#### 경계 살피고 익히기

* 외부 코드를 사용하기 위해 기술 문서를 읽고 간단하게 코드를 작성해보는 것도 좋지만, 테스트 코드를 작성하면서 내부에서 예상한 방식으로 작동하는지 확인하는 과정도 의미가 있다. (사용법을 잘 모르는 상태에서 외부 라이브러리를 사용하다보면 원인이 외부 코드에 있는지, 내부적인 사용 방식 문제인지 확신하기 어렵다.)
* 학습 테스트는 꽤 유용하다. 어차피 외부 코드를 사용하는 방법은 익혀야하고, 추후 새로운 버전이 출시되었을 때 마이그레이션을 수행하기도 쉬워진다. 적어도 우리가 사용하는 방식으로 동작하는 테스트가 전부 통과한다면 버전업에 문제는 없지 않겠는가.

<br>

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

* 아직 개발되지 않은 외부 코드에 대해 의존성을 가지고 있을 경우엔 차라리 우리가 원하는 인터페이스를 만들고, 가짜 구현체를 만들어두는 것이 나을 수 있다. 이후 실제 외부 코드가 완성되면서 Adapter 패턴을 통해 자체적으로 만든 인터페이스와 외부 코드를 결속시킨다.
* 이런 식으로 외부 코드와 내부 코드를 분리시켜놓는 패턴은 추후 외부 코드에 변경이 생기거나 다른 코드로 변경할 때 유연성을 제공한다.
*