8장 경계

인터페이스 제공자와 인터페이스 사용자 간에 긴장이 존재한다. 패키지나 프레임워크 제공자는 적용성을 넓히려고 하지만, 사용자는 자신의 요구를 충족하는 인터페이스만 집중한다. 이러한 경계에서 시스템 경계 충돌이 일어난다.

 

한 예로 java.util.Map을 살펴보면, Map은 굉장히 다양한 인터페이스로 수많은 기능을 제공한다. 기능성과 유연성이 커 유용하지만 위험도가 큰 편. 그런데 이러한 인터페이스가 프로그램을 만들면서 여러곳으로 넘기고 받게 되면 clear 메서드를 사용해 데이터를 삭제할 수도 있는 것이다. 그 밖에도 삽입 수정 등의 제한도 사라진다는 의미다.

 

해결 방안으로 캡슐화가 있다.

 

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

 

경계 인터페이스인 Map을 Sensors 안으로 숨김을 통해 Map 인터페이스가 변하더라도 제네릭스를 사용하든 안하든 문제가 일어나지 않게 된다. 또한 필요한 Sensors 클래스가 필요한 인터페이스만 제공하기 때문에 코드는 이해하기 쉬우며 오용이 어려워지게 된다. 이것은 설계 규칙과 비지니스 규칙을 강제하는 효과가 있다.

하지만 무조건 캡슐화를 하는 것이 아닌 예로 든 Map 인터페이스와 같이 경계 인터페이스를 마구잡이로 넘기고 받지 말라는 이야기다.

 

 

>>>

외부 코드를 사용하면 적은 시간에 더 많은 기능을 출시하기 쉬워지는데 외부에서 가져온 패키지를 사용하고 싶다면 어디서 어떻게 시작하면 좋겠는가.

 

테스트!

 

곧바로 우리 쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성하여 외부 코드를 익히는 방법, 학습테스트가 유용하다.

간단히 통제된 환경에서 외부API 호출하여 API를 제대로 이해하는지 확인하는 것.

 

 

>>>

아직 존재하지 않는 코드를 사용하는 건 어떤가.

팀끼리 프로젝트 진행 시 타 팀의 API가 없는 경우가 있다. 그래서 구체적인 구현을 미루고 자체적 인터페이스를 정의한다.  특히 Adapter 패턴을 통해 API 사용을 캡슐화 하여 API가 바뀔 때 수정할 코드를 한곳으로 모으는 설계가 유용하다.

https://yaboong.github.io/design-pattern/2018/10/15/adapter-pattern/

디자인패턴 - 어댑터 패턴

 

 

즉.. 요약하자면,

1. 외부 패키지에 의존하지 말고 우리의 코드에 의존해야 한다.

2. 외부 패키지 호출하는 코드를 가능한 줄여 경계를 관리해야 한다.