노션에서 정리한 내용을 벨로그로 옮겼기 때문에 노션으로 보면 조금 더 보기 더 편합니다🤗
이동하기 → junnkk's Notion
→ 개발 시 패키지, 오픈 소스, 다른 팀의 컴포넌트 등의 외부 코드를 이용할 때 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교
외부 코드 사용하기
-
인터페이스 제공자 vs 사용자
제공자 - 적용성 높이려 함.
사용자 - 자신의 요구에 집중하는 인테페이스 원함.
-
시스템 경계에서의 문제 예시 - java.utils.Map (p144~146)
→ 제네릭스 사용 시 가독성 ↑ but 여전히 필요하지 않은 기능 제공
-
해결책
: 클래스 안으로 경계 인터페이스인 Map 숨긴다
→ 클래스 안에서 객체 유형을 관리하고 변환.
→ 프로그램에 필요한 인테페이스만 제공 ∴ 코드 이해하기 쉬워지며 오용하기 어려워짐
-
∴ Map과 같은 경계 인터페이스 이용 시 이를 이용하는 클래스나 클래스 계열 밖으로 노출하지 않도록 주의.
(Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않는다)
경계 살피고 익히기
-
학습 테스트
: 우리 쪽 코드를 작성해 외부 코드를 호출하는 대신, 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히는 것
-
프로그램에서 사용하려는 방식대로 외부 API를 호출(통제된 환경에서 API를 제대로 이해하는지를 확인)
-
API를 사용하려는 목적에 초점
-
log4j 익히기
학습 테스트는 공짜 이상이다
-
학습 테스트
-
이해도를 높혀주는 정확한 실험
-
패키지 새 버전이 나오면 학습 테스트를 이용하여 차이 확인
-
패키지가 예상대로 도는지 검증
-
아직 존재하지 않는 코드를 사용하기
-
아는 코드와 모르는 코드를 분리하는 경계
→ 파악하여 바라는 인터페이스 구현 시 코드 가독성 ↑, 의도 분명하게 함.
예시) 무선 통신 시스템의 '송신기' 시스템(p150~151)
아직 설계되지 않은 API 부분의 인터페이스를 자체적으로 정의(Transmitter 클래스와 transmit 메서드- 주파수와 자료 스트림을 입력으로 받음)
깨끗한 경계
-
우수한 소프트웨어 설계 → 변경하는데 많은 투자와 재작업, 시간, 노력 필요 X.
- 경계에 위치하는 코드는 깔끔히 분리한다.
- 기대치를 정의하는 테스트 케이스 작성한다.
- 외부 패키지를 호출하는 코드를 최대한 줄여 경계 관리 → 새로운 클래스로 경계 감싸기, ADAPTER 패턴을 사용하여 우리가 원하는 인터페이스를 패키지가 제공하는 인테페이스로 변환
⇒ 코드 가독성 ↑, 경계 인터페이스를 사용하는 일관성 ↑, 오부 패키지가 변했을 때 변경할 코드 ↓
→ 9장 단위 테스트
