Clean Code - 08. 경계

경계 유형 1. 외부 코드와 우리 코드의 경계

외부 코드 사용하기

패키지 제공자/프레임워크 제공자 - 적용성을 최대한 넓히려고 함
사용자 - 자신의 요구에 집중하는 인터페이스를 바람
-> 시스템 경계에서 문제가 생길 소지가 많음

// Map이 반환하는 Object를 올바른 유형으로 반환할 책임이 Map을 사용한 클라이언트에 있음
Map sensors = new HashMap();
Sensor s = (Sensor)sensors.get(sensorId);

// 깨끗한 코드라 보기 어렵고, 의도도 분명히 드러나지 않음

// 제네릭스를 사용하여 코드 가독성을 높임
Map<String, Sensor> sensors = new HashMap<Sensor>();
Sensor s = sensors.get(sensorId);
// 사용자에게 필요하지 않는 기능까지 제공하는 문제는 해결하지 못함
// Map 인터페이스가 변할 경우, 수정할 코드가 많아짐

// 제네릭스의 사용 여부는 클래스 안에서 결정해 사용자는 제네릭스가 사용되었는지 여부에 신경 쓸 필요가 없음
public class Sensors {
    private Map sensors = new HashMap();

    public Sensor getById(String id) {
        return (Sensor) sensors.get(id);
    }
}
// 경계 인터페이스인 Map을 Sensors 안으로 숨겨 Map 인터페이스가 변하더라도 나머지 프로그램에는 영향을 미치지 않음

Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.

경계 살피고 익히기

• 학습 테스트
  • 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익힌다.
  • 프로그램에서 사용하려는 방식대로 외부 API를 호출한다. -> 통제된 환경에서 API를 제대로 이해하는지를 확인하는 셈.
  • API를 사용하려는 목적에 초점을 맞춘다.

log4j 익히기

학습 테스트는 공짜 이상이다

• 필요한 지식만 확보하는 손쉬운 방법
• 이해도를 높여주는 정확한 실험
• 투자하는 노력보다 얻는 성과가 더 큼
• 패키지가 예상대로 도는지 검증함
• 새 버전이 우리 코드와 호환되지 않으면 학습 테스트가 이 사실을 곧바로 밝혀낼 수 있음
• 이런 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워짐

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

경계 유형 2. 아는 코드와 모르는 코드를 분리하는 경계

• 우리 지식이 경계를 너머 미치지 못하는 코드 영역
• (적어도 지금은) 알려고 해도 알 수가 없을 때
• 더 이상 내다보지 않기로 결정했을 때

깨끗한 경계

소프트웨어 설계가 우수하다면 변경하는데 많은 투자와 재작업이 필요하지 않다.
경계에 위치하는 코드는 깔끔히 분리한다.
통제가 불가능한 외부 패키지에 의존하는 대신 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.
외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.

내 생각

외부 라이브러리 쓸 때 api 문서 보고 막 갖다 썼는데.. 반성합니다..