경계

프로젝트의 하나로 앱 개발을 진행할 때 앱에 필요한 모든 소프트웨어를 직접 개발하지는 않았습니다. 규격화 되어 있는 오픈 소스를 이용하고 다른 팀의 API를 사용하고 필요에 의해 비용을 지불하고 라이선스를 획득하여 사용하기도 합니다.

 

외부의 코드를 사용하게 되면 내부의 코드와 적절히 조화를 이루도록 하는 것이 중요한 부분인데 이번 장에서는 이러한 경계를 깔끔하게 처리하는 기법과 기교를 설명하고 있습니다.

외부 코드 사용하기

코드 제공자는 적용성과 범용성을 넓히기 위해 최대한 노력합니다. 하지만 이러한 적용성과 범용성이 단점으로 다가오는 상황도 존재합니다. 너무 많은 기능을 제공해버리면 클라이언트에서 필요하지 않은 기능까지 제공해버리게 됩니다.

 

이를 적절히 캡슐화하여 기능을 제한하면 클라이언트로서 편할 것 같다는 생각이 듭니다. 경계 인터페이스를 사용하고자 하는 클래스 안으로 숨기고 필요한 기능만 드러내 사용하도록 합니다. 이 방법을 통해 경계 인터페이스의 변화가 발생하더라도 해당 클래스만 수정하면 되기에 유지보수에도 용이합니다.

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

해당 설명은 그림으로 이해하는 것이 쉽기에 그림으로 설명하겠습니다.

경계는 외부 코드와의 경계도 존재하지만, 아는 코드와 모르는 코드 사이의 경계도 존재합니다. 다른 팀과의 협업을 통해 API를 개발한다고 했을 때 제일 처음으로 큰 인터페이스를 정의합니다. API로 사용될 메서드가 있을 것이고 필요한 매개변수가 존재합니다.

 

다음으로는 인터페이스에서 통제하고 구현하기 어려운 것들은 분리합니다. 이 과정을 통해 인터페이스가 깔끔해지고 깨끗해집니다. API 구현체는 ADAPTER 패턴으로 API 사용을 캡슐화하여 구현체가 바뀔 때 변경되는 코드들을 한곳으로 모읍니다. 변경 가능성과 확장성에 열려 있는 설계가 가능해집니다.

 

이러한 방법은 테스트도 쉽습니다. 적절한 테스트 구현체를 구현하기만 한다면 손쉽게 인터페이스를 테스트할 수 있습니다.

마치며

경계를 적절히 구분한다는 것은 클래스의 역할과 책임에 맞게 잘 구분했다는 말과 같다는 생각이 들었습니다. 이는 객체 지향 프로그래밍을 위해서는 필수적으로 필요한 작업이기에 적절한 경계 구분을 위해 많은 코드를 작성해볼 것입니다.