모호한 경계를 구분짓기 #7

목차

• 경계
• 경계 짓기 (1) 우리 코드를 보호하기
• 경계 짓기 (2) 외부 코드와 호환하기
• 외부 라이브러리 테스트하기 - Learning Test

경계

• 오픈소스, 라이브러리를 안쓰는 프로젝트는 없다.
• 우리가 만든 코드에 외부에서 들어온 코드를 병합해야 한다.
• 외부 코드는 외부에서 만든 코드인데, 외부 시스템과 호출하거나 단순히 외부에서 만들어진 코드일 수 있다.
• 우리 코드와 외부코드를 깔끔하게 통합시키기 위해 경계를 잘 지어야 한다.

경계 짓기(1) 우리 코드를 보호하기

캡슐화(Encapsulation)

객체의 실제 구현을 외부로부터 감추는 방식

우리 코드를 보호하기

Sensor 를 관리하고 싶다. Sensor는 외부에서 사용된다.

• Sensor id와 Sensor 객체로 저장하고 싶어서, Map을 사용한다.
• 하지만 Map을 그대로 사용하면 Map이 가진 Clear()가 외부로 노출된다.
• Sensor의 '외부' 코드 관점에서 Sensor 객체의 값들만 가져오고 싶다.

=> 캡슐화 한다!

 

// Bad
Map<Sensor> sensors = new HashMap<Sensor>();
Sensor s = sensors.get(sensorId);

• Map 인터페이스가 제공하는 clear 등 불필요한 기능이 노출된다.
• 외부 코드가 함추를 함부로 호출하면 sensor 데이터가 손상될 수 있다.

// Good
public class Sensors {
    private Map<Sensor> sensors = new HashMap<Sensor>();
    
    public Sensor getById(String sensorId) {
    	return sensors.get(sensorId);
    }
}

• 캡슐화를 통해 Map을 감춘다.
• 원하는 기능만 공개할 수 있다.
• 적절한 경계로 우리 코드를 보호할 수 있다.

경계 짓기(2) 외부 코드와 호환하기

외부 코드를 호출 할 때 우리가 원하는 방식으로 사용하고 싶다면 Adapter 패턴을 사용한다.

• 우리가 원하는 방식인 read할 때 ByteBuffer[]로 parameter를 보내면, 외부 코드인 nettyChannel에 ByteBuf 타입으로 parmeter 을 변환하여 전달한다.
• Page[] 타입 parameter로도 전달할 수 있다. Adapter에 매서드를 추가해 우리가 원하는 타입의 파라미터를 전달할 수 있다.
• 만약 adapter를 통한 변환을 거치지 않았다면 nettyChannel 에 데이터를 전달할 때마다 타입을 변환하는 과정이 필요했고,  이는 중복을 발생시켰을 것이다.

Adapter패턴 구조

Learning Test 를 작성해 라이브러리를 테스트한다.

라이브러리는 자기들이 이미 테스트를 했겠지.. 

근데 라이브러를 '사용'하는 내가 테스트를 한다고????

외부 코드를 배우고, 안정성도 미리 검즐할 수 있다.

• 학습 테스트는 이해도를 높인다.
• 외부 코드의 버전이 변경됐을 때, 우리 코드와 호환되는 지 확인할 수 있다.