외부 코드를 사용할때 경계를 처리하는 방식에 대한 내용이다.

외부 코드 사용하기

패키지 제공자나 프레임워크 제공자는 최대한 넓은 기능을 제공하려고 한다.

그러나 사용자는 자신에 요구사항에 맞는 인터페이스를 바란다.

이런 부분에서 경계 처리가 필요하다.

ex) java.util.Map

Map에는 많은 함수들을 제공한다.

그러다보면, Map 데이터를 서로 주고 받다보면

Map 데이터를 받은 누구나 clear로 데이터를 날릴 수 있는 위험이 있다.

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 클래스 안으로 숨기면 내가 제공하고 싶은 method만 제공할 수 있다.

경계 살피고 익히기

외부 코드를 익히는 방법으로 이 책에서는

먼저 간단한 테스트 케이스와 테스트 코드로 “학습 테스트”를 진행하길 추천한다.

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

학습 테스트는 이해도를 높여줄뿐 아니라 패키지 버전이 올라갔을때

문제 없이 올려도 되는지 테스트를 해준다는 장점이 있다.

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

서로 협업하는 구조나 내가 개발하지 않는 영역의 코드를 사용해야할때

미리 인터페이스를 작성하고 해당 내용 테스트 케이스를 작성하여 개발하는 방식을 추천한다.

어댑터 패턴으로 구성하면 해당 API 내용이 바뀔때마다 수정할 코드를 한곳으로 모을 수 있다.

요약

이번 내용을 보며 블루투스 개발 내용에 반영을 해보았다.

나도 Map 데이터로 서로 주고 받았던 부분을 감싸서 클래스로 추가해보았다.

확실히 인터페이스를 정의해서 사용하도록 하는게 안전하다는 생각이 들었고,

단점으로는 어쨋든 관리해야하는 코드와 파일이 늘어났다는 점이지만

그래도 장점이 더 큰 것 같다.

핵심 라이브러리들은 특히나 어댑터 패턴으로 인터페이스를 정의해서 개발하는게 좋을것 같다.

하지만… 매번 속도때문에 넘어가는 경우가 많다….