어댑터 패턴 (Adapter Pattern)은 언제 사용해야 할까?

요구사항

클라이언트가 서로 다른 2개의 클래스에 의존하고자 할 때, 하나의 추상화된 인터페이스로 의존되어야 한다.

클래스 다이어그램으로 나타내면 위와 같다.  DoClass는 do()라는 퍼블릭 메서드를 갖고 있으며, RunClass는 run()이라는 퍼블릭 메서드를 갖고 있다. 메서드 명부터 다른 2개의 클래스를 하나의 추상화된 인터페이스로 의존하고자 한다면 어떻게 해야 할까?

방법 1 : 클래스를 수정한다. (전략 패턴)

간단하게 하는 방법은 클래스들의 코드를 수정하여서 인터페이스를 구현하도록 코드를 수정한다. 각기 다른 메서드 명도 통일시킨다면 클라이언트가 하나의 인터페이스를 통해 달라지는 (혹은 확장되는) 클래스들을 의존할 수 있게 된다.

 

추가 요구사항

만약 의존하는 클래스들의 코드를 수정할 수 없다면?

 

의존하는 클래스들의 코드를 수정할 수 없는 경우가 종종 있다. 예를 들면 외부 라이브러리를 사용하는 경우라던가, 다른 의존관계에 영향을 준다던가 혹은 수정해야 하는 코드의 양이 너무 많다면 수정하기가 힘들다. 

 

이런 경우에, 어댑터 패턴 (Adapter Pattern)을 적용해 볼 수 있다. 

 

전략 패턴과 어댑터 패턴을 고려할 때 가장 중요한 전제가 이 사항이다. 의존하는 클래스의 코드가 수정 가능하다면 전략 패턴이 좀 더 간단한 해결방법 된다. 그렇지 않다면 어댑터 패턴이 고려되어야 한다.

방법 2: 인터페이스와 의존하고자 하는 클래스 사이에 어댑터를 둔다. (어댑터 패턴)

'어댑터'라는 단어는 변환기로써 실생활에서도 종종 사용된다. 이와 마찬가지로 DoAdapter와 RunAdapter를 사이에 둔다면 DoClass와 RunClass의 수정 없이 요구사항을 만족시킬 수 있다.

 

코드로 나타낸다면 다음과 같다.

class DoAdapter implements MyInterface {
    @Override
    public void execute() {
    	DoClass doObject = new DoClass();
        doObject.do();
    }
}

class RunnAdapter implements MyInterface {
    @Override
    public void execute() {
    	RunClass runObject = new RunClass();
        runOject.run();
    }
}

결론

수정이 불가능한 여러 개의 객체를 하나의 타입(인터페이스)으로 의존하고자 할 때 어댑터 패턴을 사용하자.