[Design Pattern] 어댑터 패턴 고찰

어댑터 패턴(Adapter Pattern)

1. 정의

　- 연관성 없는 두 객체 묶어 사용하기

　- 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환합니다. 이 패턴을 사용하면 다른 인터페이스와의 호환성 문제를 해결할 수 있습니다.

2. 의도

　- 이미 제공되는 기능이 형태가 달라, 필요로 하는 형태로 변경하고자 할 때

　- 활용

　　- 기존의 클래스를 사용해야 하나 인터페이스가 수정되어야 하는 경우

　　- 기존 라이브러리 모양을 달리하여 재사용하고자 할 경우

　- 예제

　　- LED 프레임워크가 제공되어졌다.

　　　LED를 끄고 RGB 색상으로 켜고 하는 메서드들을 제공받았다.

　- 정리

　　- Object Adapter 패턴을 일반적으로 많이 사용합니다. (Adaptee를 멤버변수로 활용하는 방식)

　　- Object Adapter 패턴을 사용하면, Adaptee 클래스의 하위 클래스에 대해서도 소스코드 변경없이, 이를 활용하여 새로운 기능 추가가 편리합니다.

　　하지만, 우리 하드웨어는 켜있는 상태에서 다른 색상을 켜면 색이 섞이는 현상이 생겨서, 무조건 한번 끄고 색상을 켜는 기능을 추가로 하고 싶다면?

　　프레임워크를 수정해버리면, 하드웨어가 바뀌면 또 다시 프레임워크를 되돌려야 하는 부담감이 있습니다.

Question. Decorator vs. Adapter vs. Facade vs. (Proxy) ?

유사한 부분: Composition & Delegation !

- Decorator : object를 감싼 동작을 구현

- Adpater : interface를 감싸서 호출을 위임

- Facade : 하나 이상의 interface를 감싸고 사용하기 쉬운 중앙 집중된 interface 제공

- Proxy : Subject를 감싸고 호출을 위임

차이점: Intent !

- Decorator : 실행 시점에 새로운 기능을 추가합니다. 심지어 생성 후에도 object의 기능을 추가할 수 있게(enrich) 합니다.

- Adapter : interface 전환(convert)

　두 개의 컴포넌트가 같이 동작하게 합니다. 두 개가 같이 동작하지 않는 것은 두 컴포넌트의 interface가 맞지 않기(incompatible) 때문입니다.

- Facade : interface 전환도 새로운 기능 추가도 아닙니다. 대신 간단한 interface를 제공해서 클라이언트가 직접 시스템 내부의 개별 컴포넌트에 접근하게 하는 대신에 Facade를 사용합니다.

- Proxy : object 접근 제어가 목적입니다. Proxy는 클라이언트의 직접적인 접근을 막는 대신, 실제 object처럼 동작합니다. 그리고 실제 object처럼 동작하고 다른 행동을 하거나 원래 object에 요청을 보낼 수도 있습니다. 예를 들어, 원격 object와 통신하는 Remote proxy, 비용이 많이 드는 object에 접근을 통제하는 Virtual proxy, role 기반 object의 접근을 제공하는 Protection proxy, 캐시 object를 반환하는 Caching proxy 등에 사용될 수 있습니다.

Question. If so, Difference between these in java?

Difference between Adapter and Decorator

　Adpater 패턴은 인터페이스를 전환하지만, Decorator는 interface를 전환하지는 않고 단지 원본 object를 받아들이는 메서드에 전달될 수 있도록 원본 object의 interface를 구현할 뿐.

Difference between Decorator and Facade

　새로운 동작을 추가하는지의 유무

　Facade는 새로운 동작을 추가하지 않고 단지 interface에 있는 메서드를 호출할 뿐.

Difference between Decorator and Proxy

　1) Decorator는 절대 object를 생성하지 않고, 항상 존재하는 object에 새 기능을 추가합니다. 반면 Proxy는 object가 존재하지 않으면 object를 생성할 수 있습니다. 준비될 때까지 실제 object처럼 있다가(stand in place of real object... and then) 실제 object에 요청을 전달할 수 있습니다.

　2) Decorator는 여러 decorator를 연결(chaining)해서 여러 기능(feature)을 추가할 수 있고 순차적인 방식으로 기능을 동작시킬 수 있습니다. 반면 Proxy는 proxy 연결(chaining)을 권하지는 않습니다.

Question. When to use these patterns?

상황 1. 클라이언트가 복잡한 시스템에 단순하게 접근하게 하려면?

상황 2. 두 개의 다른 부분을 같이 동작하게 할 Interface로 변환해야 한다면?

상황 3. 런타임으로 기존 object에 새로운 동작을 추가해야 한다면?

상황 4. 보안이나 성능, 네트워킹 등의 이유로 실제 object를 숨겨야 한다면?