챕터 8. 경계

외부코드 사용하기

패키지, 프레임워크 제공자는 적용성을 최대한 넓히려고 한다. 반면 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이런 상황으로 인해 시스템 경계는 문제가 생길 소지가 많다.

한 예로, java.util.Map을 보자. Map은 굉장히 다양한 인터페이스로 수많은 기능을 제공한다. Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 크다.

Map <String, Sensor> sensor = new HashMap();

예를 들어 위와 같은 코드를 작성했다고 가정하고, 프로그램에서 이 인스턴스를 여기저기로 넘긴다면, Map 인터페이스가 변할 경우 수정할 코드가 상당히 많아진다.

public class Sensors{
	private Map sensors = new HashMap();
    public Sensor getById(String id){
    	return (Sensor) sensors.get(id);
    }
}

이를 해결하기 위해서는 Map을 Sensors안으로 숨기는 것이다. '일급 컬렉션'이라는 개념을 적용 시킨 것이며, 이것 말고도 Map 인스턴스를 공개 API의 인수로 넘기거나 반환값으로 사용하지 않아야한다.

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

학습 테스트는 패키지가 예상대로 도는지 검증한다. 추가한 패키지가 우리 코드와 호환되리라는 보장은 없다. 패키지 작성작에게 코드를 변경할 필요가 생길지도 모른다. 패키지는 새 버전이 나올때마다 새로운 위험이 생긴다.

학습 테스트를 이용하여 패키지가 우리 프로그램 코드와 문제가 없는지 확인해야한다. 학습 테스트를 이용한 학습이 필요하든 그렇지 않든, 실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다.

• 아직 존재하지 않는 코드를 사용하기 : 팀 프로젝트를 하다보면 다른 팀에서 완성하지 못한 API를 써야할 때가 있을 것이다. 자체적으로 경계 인터페이스를 정의해서 사용해야한다.
• 클린 경계 : 우수한 소프트웨어 설계는 변경을 위해 많은 투자와 재작업이 필요하지 않다. 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.

8강 후기

이번 장에서는 소프트웨어의 깔끔한 경계처리 방법에 대해 배웠다. 프로젝트에서 어떠한 기능을 사용하기 위해 새로운 라이브러리를 사용하게 되고, 그 라이브러리에 맞춰서 기존에 있던 코드가 변하는 경우가 있었는데, 그러한 상황을 최대한 발생하지 않도록 해야한다는 것을 알게됐다.