8. 경계

※ 해당 포스트는 책의 내용을 요약 / 정리 한 내용으로 내용이 생략되거나 추가됐을 수 있습니다. 

 

[소프트웨어의 경계]

소프트웨어의 경계란?

• 오픈 소스, 패키지 제공자로 부터 구입한 패키지 코드, 사내 다른 팀이 제공한 코드 등 외부 코드와 우리 코드가 만나는 영역(인터페이스)

패키지 제공자와 사용자 간의 문제

• 제공자: 더 많은 환경에서 패키지를 구동하기 위해 넓은 적용성의 인터페이스를 제공한다.
• 사용자: 자신의 요구(우리 코드에 필요한 만큼) 에 집중하는 인터페이스를 제공받기를 원한다.

문제의 해결법

- 외부 코드를 감싸는 코드를 만들고 우리 코드에 필요한 인터페이스만 제공한다. (Facade 패턴)

- 공개해야 하는 API 의 인수/ 반환 값으로 외부 코드를 사용하지 않는다.

 

[외부 패키지 익히기]

외부 패키지를 사용하기 위해 패키지를 학습하는 방법

• 학습 테스트 : 기능 구현을 위한 테스트가 아니라 외부 패키지가 어떻게 동작하는지 검증하기 위한 테스트

학습 테스트

• 다양한 조건에서 기능을 손쉽게 확인할 수 있다.
• 외부 패키지의 버전 업그레이드 시 호환성 검증을 학습 테스트를 통해 진행할 수 있다.
• 테스트코드 작성법을 익히는 좋은 훈련이 될 수 있다.

MUI 라는 외부 패키지를 테스트하기 위해 테스트 코드를 작성한 예제

[아직 존재하지 않는 코드]

경계는 아는 코드와 모르는 코드를 분리하는 영역일 수 있다.

• 다른 팀과 협업 시 다른 팀이 아직 개발 중인 API를 사용해야하는 부분을 우리 코드에서 사용해야 할 수 도 있다.

경계 영역에 인터페이스를 만들고 해당 인터페이스를 구현하는 Fake API class 를 구현해 개발을 하고 추후 다른 팀의 API 개발이 완료되면 해당 코드를 사용한 class를 구현한다.  

• 이 때 Adapter 패턴을 사용해 API 사용을 캡슐화 한다. 

 

[Adapter 패턴]

한 클래스의 인터페이스를 클라이언트에서 사용하고자하는 다른 인터페이스로 변환하는 패턴

 

 

참고: https://jihyehwang09.github.io/2019/11/17/design-pattern-adapter-pacade/

어댑터 패턴(Adapter pattern)과 퍼사드 패턴(Pacade pattern)

https://invincibletyphoon.tistory.com/20

어댑터 패턴(Adapter Pattern)