[Study][CleanCode - 2] 8. 경계

📋 목차.

8. 경계
    .외부 코드 사용하기
    .경계 살피고 익히기
    .학습 테스트는 공짜 이상이다.
    .아직 존재하지 않는 코드를 사용하기
    .깨끗한 경계

---

✔️ 내용.

 

8. 경계

 

 

 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다.
패키지를 사기도 하며 오픈소스를 이용한다. 사내 다른 팀이 제공하는 컴포넌트를 사용하는 경우도 있다.
어떤 식으로든 외부 코드를 우리 코드에 깔끔하게 통합해야 한다.
 이번 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다.

 

---

 

.외부 코드 사용하기

 

 자주 사용 Collections인 Map을 예로 보자

 

// 1
Map sensors = new HashMap(); 
Sensor s = (Sensor)sensors.get(sensorId);

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

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

 

1의 경우 반환하는 Object를 Sensor으로 변환하는 책임을 Map을 사용하는 클라이언트에게 주게 된다.

2의 경우는 제네릭을 사용함으로 써 코드 가독성을 크게 높일 뿐 1의 경우와 같이 책임은 클라이언트에게 있다.

또한 1, 2는 사용자가 필요하지 않은 Map의 다른 기능까지 제공하게 된다. 이러한 Map 인스턴스를 여기저기로 넘긴다면, Map 인터페이스가 변경될 경우 수정될 코드가 상당히 많아진다.

 

 따라서 3과 같이 경계 인터페이스인 Map을 Sensors 안으로 숨겨 Sensors 클래스 안에서 객체 유형을 관리하도록 한다.

그렇게 될 경우 Map 인터페이스가 변하더라도 나머지 프로그램에 영향을 미치지 않는다. 또한 Sensors 클래스는 프로그램에 필요한 인터페이스만 제공한다. 그래서 코드는 이해하기 쉽지만 오용하기는 어렵다. Sensors 클래스는 다른 프로그램들이 설계 규칙과 비즈니스 규칙을 따르도록 강제할 수 있다.

 

 Map을 사용할 때마다 3과 같이 캡슐화하라는 의미가 아니라. 경계 인터페이스(Map)를 여기저기 넘기지 말라는 말이다

경계 인터페이스의 인스턴스를 공개 API의 인수로 넘기거나 반환 값으로 사용하지 않는다.

 

---

 

.경계 살피고 익히기

 

 외부 API를 가져올 경우 외부 API를 너무 신뢰하지 말고 간단한 테스트 케이스를 작성해 익히도록 한다.

짐 뉴커크는 이를 학습 테스트라고 부른다.

 

 학습 테스트는 프로그램에서 사용하려는 방식대로 외부 API를 호출한다. 통제된 환경에서 API를 제대로 이해하는지 확인하는 셈이다. 학습 테스트는 외부 API를 사용하는 목적에 초점을 맞춘다.

 

---

 

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

 

 학습 테스트에 드는 비용은 없다. 어차피 API를 배워야 하기 때문이다. 

오히려 필요한 지식만 확보하는 손쉬운 방법이다. 학습 테스트는 이해도를 높여주는 정확한 실험이다.

 

 학습 테스트를 이용한 학습이 필요하든 그렇지 않든, 실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다. 이런 경계 테스트가 있다면 패키지는 새 버전으로 이전하기 쉬워진다. 

 

---

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

 

 경계와 관련해 또 다른 유형은 아는 코드와 모르는 코드를 분리하는 경계이다. 

우리가 원하는 인터페이스를 구현하고 Adapter 패턴으로 API 사용을 캡슐화하여 모르는 코드가 바뀔 때 수정할 코드를 한 곳으로 모은다. 이와 같은 설계는 테스트 또한 편하게 진행이 가능하다.

 

---

 

.깨끗한 경계

 

 경계에서는 다양한 일이 발생하는데 변경이 대표적인 예다. 

소프트웨어 설계가 우수하다면 변경하는데 많은 자원이 필요하지 않다. 경계에 위치하는 코드는 깔끔히 분리한다.

또한 기대치를 정의하는 테스트 케이스도 작성한다. 통제가 불가능한 외부 코드보다는 통제가 가능한 우리 코드에 의존하는 편이 훨씬 좋다.

 

 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하다. Map에서 봤듯이 새로운 클래스로 경계를 감싸거나, Adapter 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자.

어느 방법이든 코드 가독성이 높아지며, 경계 인터페이스를 사용하는 일관성도 높아져 외부 패키지가 변했을 때 변경할 코드도 줄어든다.

 

---

 

📝 느낀점.

 - 경계를 명확히 나누는 게 중요하다 느꼈다.
 - 외부 API 사용 시 테스트 케이스 작성의 필요성을 갖자.