<div id="readability-page-1" class="page"><article>
 
 <div>
 <h3 id="개요">개요</h3>
<ul>
 <li>어댑터 패턴에 대해서 알아본다.</li>
 <li><a target="_blank" href="https://www.coursera.org/learn/design-patterns">Coursera 의 디자인패턴 강의</a>
를 기반으로 작성했다.</li>
 <li>Rectangle vs LegacyRectangle, Duck vs Turkey 같은 터무니 없는 예제가 아닌 조금 더 실질적인 예제를 사용해본다.</li>
 <li>JDK 에 사용된 어댑터 패턴을 살펴본다.
</li>
</ul>



<h3 id="어댑터-패턴">어댑터 패턴</h3>
어댑터 패턴은 이름대로 어댑터처럼 사용되는 패턴이다. 220V 를 사용하는 한국에서 쓰던 기기들을, 어댑터를 사용하면 110V 를 쓰는곳에 가서도 그대로 쓸 수 있다.
이처럼, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해주는 패턴이 어댑터 패턴이라고 할 수 있겠다.
이를 위해 어댑터 역할을 하는 클래스를 새로 만들어야 한다.

기존에 있는 시스템에 새로운 써드파티 라이브러리가 추가된다던지, 
레거시 인터페이스를 새로운 인터페이스로 교체하는 경우에 코드의 재사용성을 높일 수 있는 방법이 어댑터 패턴을 사용하는 것이다.

구조를 보면 아래와 같다.

<figure>
 <a href="https://s3.ap-northeast-2.amazonaws.com/yaboong-blog-static-resources/diagram/adapter-pattern-1.png" target="_blank">
 <img src="https://s3.ap-northeast-2.amazonaws.com/yaboong-blog-static-resources/diagram/adapter-pattern-1.png" alt="Adapter Pattern">
 </a>
 
 <figcaption>[그림1] Coursera Design Pattern 강의 중</figcaption>
 
</figure>

Client 써드파티 라이브러리나 외부시스템을 사용하려는 쪽이다.

Adaptee 써드파티 라이브러리나 외부시스템을 의미한다.

Target Interface Adapter 가 구현(implements) 하는 인터페이스이다. 클라이언트는 Target Interface 를 통해 Adaptee 인 써드파티 라이브러리를 사용하게 된다.

Adapter 
Client 와 Adaptee 중간에서 호환성이 없는 둘을 연결시켜주는 역할을 담당한다.
Target Interface 를 구현하며, 클라이언트는 Target Interface 를 통해 어댑터에 요청을 보낸다.
어댑터는 클라이언트의 요청을 Adaptee 가 이해할 수 있는 방법으로 전달하고, 처리는 Adaptee 에서 이루어진다.



<h3 id="어댑터-패턴-호출-과정">어댑터 패턴 호출 과정</h3>

<figure>
 <a href="https://s3.ap-northeast-2.amazonaws.com/yaboong-blog-static-resources/diagram/adapter-pattern-2.png" target="_blank">
 <img src="https://s3.ap-northeast-2.amazonaws.com/yaboong-blog-static-resources/diagram/adapter-pattern-2.png" alt="Adapter Pattern">
 </a>
 
 <figcaption>[그림2]Adapter Pattern Sequence Diagram</figcaption>
 
</figure>

클라이언트에서는 Target Interface 를 호출하는 것 처럼 보인다.
하지만 클라이언트의 요청을 전달받은 (Target Interface 를 구현한) Adapter 는 자신이 감싸고 있는 Adaptee 에게 실질적인 처리를 위임한다.
Adapter 가 Adaptee 를 감싸고 있는 것 때문에 Wrapper 패턴이라고도 불린다.



<h3 id="어댑터-패턴-사용예제">어댑터 패턴 사용예제</h3>
Coursera 의 디자인 패턴 강의 중 어댑터 패턴에 나오는 예제를 조금 수정해서 구현해 보려한다.
이해를 돕기위해 어댑터 패턴의 설명에 불필요하다고 생각하는 메소드와 코드는 제거했다.

위에서 Client, Target Interface, Adapter, Adaptee 가 나오는 다이어그램을 그대로 구현한 코드다.
UML 을 그려보면 아래와 같다.

<figure>
 <a href="https://s3.ap-northeast-2.amazonaws.com/yaboong-blog-static-resources/diagram/adapter-pattern-3.png" target="_blank">
 <img src="https://s3.ap-northeast-2.amazonaws.com/yaboong-blog-static-resources/diagram/adapter-pattern-3.png" alt="Coursera Design Pattern 강의 중">
 </a>
 
 <figcaption>[그림3] Coursera Design Pattern 강의 중</figcaption>
 
</figure>

헷갈리지 않도록 위 그림과 코드에 사용되는 클래스들을 간단히 설명하면,

<table>
 <thead>
 <tr>
 <th>그림1</th>
 <th>그림3</th>
 <th>코드</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <td>Client</td>
 <td>WebClient</td>
 <td>AdapterDemo</td>
 </tr>
 <tr>
 <td>Target Interface</td>
 <td>WebRequester</td>
 <td>WebRequester</td>
 </tr>
 <tr>
 <td>Adapter</td>
 <td>WebAdapter</td>
 <td>WebAdapter</td>
 </tr>
 <tr>
 <td>Adaptee</td>
 <td>WebService</td>
 <td>FancyRequester</td>
 </tr>
 </tbody>
</table>

시나리오는 다음과 같다.

기존에는 WebClient 에서는 요청에 대한 처리로 doWork() 메소드를 호출하는데, 이 처리는 WebRequester 인터페이스를 구현한 OldWebRequester 에게 위임하도록 되어있다.
이때, WebRequester 인터페이스를 구현한 OldWebRequester 의 requestHandler() 를 호출한다.

하지만 이 OldWebRequester 를 써드파티 라이브러리인 FancyRequester 로 변경해야하는 상황이 생겼다고 가정하자.
이때 어댑터 패턴을 적용하여 기존의 코드와 써드파티 라이브러리 어느쪽도 수정하지 않고 FancyRequester 를 적용할 수 있다.

코드를 보자.

<h6 id="webrequester-interface">WebRequester «Interface»</h6>
<div><pre><code>public interface WebRequester {
 void requestHandler();
}
</code></pre></div>
Target Interface 이다. 구현체를 가지지 않고 requestHandler() 메소드에 대한 정의만 되어있다.



<h6 id="webclient">WebClient</h6>
<div><pre><code>public class WebClient {
 private WebRequester webRequester;

 public WebClient(WebRequester webRequester) {
 this.webRequester = webRequester;
 }

 public void doWork() {
 webRequester.requestHandler();
 }
}
</code></pre></div>

doWork() 는 WebRequester 인터페이스를 구현한 클래스의 requestHandler() 메소드를 호출하여 동작한다.



<h6 id="oldwebrequester">OldWebRequester</h6>
<div><pre><code>public class OldWebRequester implements WebRequester {
 @Override
 public void requestHandler() {
 System.out.println("OldWebRequester is working");
 }
}
</code></pre></div>
시나리오상에서, 기존에 사용하고 있던 WebRequester 의 구현클래스로써, WebClient 에서 doWork() 를 호출하면 내부에서 호출되던 녀석이다.
설명의 편의를 위해 작성했을 뿐, 이 예제의 Client 에서는 사용되지 않는다.



<h6 id="fancyrequester">FancyRequester</h6>
<div><pre><code>public class FancyRequester {
 public void fancyRequestHandler() {
 System.out.println("Yay! fancyRequestHandler is called!");
 }
}
</code></pre></div>

사용할 써드파티 라이브러리인 FancyRequester 이다. Adaptee 가 되겠다.



<h6 id="webadapter">WebAdapter</h6>
<div><pre><code>public class WebAdapter implements WebRequester {
 private FancyRequester fancyRequester;

 public WebAdapter(FancyRequester fancyRequester) {
 this.fancyRequester = fancyRequester;
 }

 @Override
 public void requestHandler() {
 fancyRequester.fancyRequestHandler();
 }
}
</code></pre></div>

어댑터를 위와같이 작성해준다.

WebAdapter 는 Target Interface 인 WebRequester 인터페이스를 구현하고, 인스턴스 생성시 FancyRequester 클래스를 주입한다. 
(FancyRequester 는 보통 또다른 어떤 인터페이스를 구현한 클래스이겠지만, 굳이 또 만들면 이해하기 복잡해지니까 그냥 구현 클래스만 언급했다)

그리고 Target Interface 인 WebRequester 인터페이스의 requestHandler() 를 구현하는데, 
이때 주입시킨 FancyRequester 의 fancyRequestHandler() 메소드를 호출하도록 만든다.

이렇게 하면 WebAdapter 도 WebRequester 인터페이스를 구현했으므로, WebRequester 인터페이스의 구현체를 받아 동작하던 WebClient 에 WebAdapter 를 넘겨줄 수 있고,
기존에 WebClient 에서 requesterHandler() 메소드를 호출하던 코드는 그대로 두면서도,
WebAdapter 의 requestHandler() 를 통해 써드파티 라이브러리인 FancyRequester 를 사용할 수 있게 된다.



<h6 id="실행">실행</h6>
<div><pre><code>public class AdapterDemo {
 public static void main(String[] args) {
 WebAdapter adapter = new WebAdapter(new FancyRequester());
 WebClient client = new WebClient(adapter);
 client.doWork();
 }
}
</code></pre></div>

위 예제 코드로 실행해보면 FancyRequester 가 동작하는 것을 확인할 수 있다.



<h3 id="why">WHY</h3>
<blockquote>
 애초에 두개의 인터페이스가 달라서 호환이 안된다면, 하나를 바꿔서 되게 하던지, 아니면 둘다 바꾸면 되지 않나?
</blockquote>

예제에서는 이해를 돕기위해 FancyRequester 를 인터페이스를 만들지도 않았고 클래스 내부도 훤히 들여다 볼 수 있다.
하지만, FancyRequester 가 오픈소스가 아니라 미리 컴파일된 클래스 바이너리 파일만을 제공받은 써드파티 라이브러리라면 직접적인 접근이 불가능 할 수 있다.
직접적으로 접근할 수 있는 경우라 하더라도 Adaptee 쪽에서 우리가 변경한 코드로 인해 라이브러리나 벤더쪽 시스템 전체가 깨질 수도 있다.

<blockquote>
 그러면 우리쪽 인터페이스를 수정하면 되지 않나?
</blockquote>

가능할 수 있다. 하지만 바꾸려는 우리쪽 인터페이스를 우리 시스템의 다른 어딘가에서 사용하고 있다면? 그 부분도 수정해줘야 한다.
우리쪽 인터페이스를 수정하고, 이에 영향을 받는 부분들을 수정하다가 예기치 못한 오류가 발생할 가능성이 매우 크다.



<h3 id="jdk-에-사용된-어댑터-패턴">JDK 에 사용된 어댑터 패턴</h3>
어댑터 패턴이 적용된 가장 대표적인 예가 자바의 InputStreamReader 이다.
콘솔에서 입력을 받을 때 아래와 같이 사용하는 것을 본 적이 있을 것이다. (알고리즘 문제풀때 자바로 하면 Scanner 클래스를 사용하지 않고 이렇게 많이 했던 것 같다)

<div><pre><code>BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
</code></pre></div>

BufferedReader 클래스를 까서 위 구문이 실행될때 사용되는 생성자를 보면 아래와 같이 Reader 타입을 받는다.

<div><pre><code>public BufferedReader(Reader in) {
 this(in, defaultCharBufferSize);
}
</code></pre></div>

하지만 System.in 은 InputStream 타입을 반환한다.

<div><pre><code>public final static InputStream in = null;
</code></pre></div>

자바의 InputStream 은 바이트 스트림을 읽어들인다. 하지만, BufferedReader 는 캐릭터인풋 스트림을 읽어들인다.
둘은 호환되지 않는다. 하지만, 이 둘을 연결시켜 주는 어댑터가 InputStreamReader 클래스이다.
UML 로 보면 아래와 같은 구조다.

<figure>
 <a href="https://s3.ap-northeast-2.amazonaws.com/yaboong-blog-static-resources/diagram/adapter-pattern-4.png" target="_blank">
 <img src="https://s3.ap-northeast-2.amazonaws.com/yaboong-blog-static-resources/diagram/adapter-pattern-4.png" alt="Adapter Pattern used in JDK">
 </a>
 
 <figcaption>Adapter Pattern used in JDK</figcaption>
 
</figure>

BufferedReader 클래스는 Reader 클래스를 상속받는다. (Reader 클래스는 Readable 인터페이스를 구현한 추상클래스이다),
InputStreamReader 클래스도 Reader 클래스를 상속받는다.
둘 다 Reader 클래스의 서브클래스 이므로 Reader 타입으로 레퍼런스 할 수 있다.

그리고 InputStreamReader 클래스는 InputStream 타입을 받을 수 있는 생성자를 가지고 있으므로,
System.in 을 InputStreamReader 인스턴스 생성시 넘겨주는 방식이다.

InputStreamReader 클래스를 Adapter, System.in 을 Adaptee, Reader 를 Target Interface 라고 할 수 있겠다.



<h3 id="어댑터-패턴-정리">어댑터 패턴 정리</h3>
<ul>
 <li>Adaptee 를 감싸고, Target Interface 만을 클라이언트에게 드러낸다.</li>
 <li>Target Interface 를 구현하여 클라이언트가 예상하는 인터페이스가 되도록 Adaptee 의 인터페이스를 간접적으로 변경한다.</li>
 <li>Adaptee 가 기대하는 방식으로 클라이언트의 요청을 간접적으로 변경한다.</li>
 <li>호환되지 않는 우리의 인터페이스와 Adaptee 를 함께 사용할 수 있다.</li>
</ul>



<h3 id="결론">결론</h3>
사용해야하는 인터페이스가 현재의 시스템과 호환되지 않는다고 해서 현재의 시스템을 변경을 해야하는 것은 아니다.



<h3 id="참고한-자료">참고한 자료</h3>
<ul>
 <li><a target="_blank" href="https://www.coursera.org/lecture/design-patterns/2-1-6-adapter-pattern-RRZST">[Coursera - University of Alberta] Design Patterns 2.1.6 - Adapter Pattern</a></li>
 <li><a target="_blank" href="https://howtodoinjava.com/design-patterns/structural/adapter-design-pattern-in-java/">[HowToDoInJava] Adapter Design Pattern in Java</a></li>
 <li><a target="_blank" href="http://tutorials.jenkov.com/java-io/inputstream.html">[JENKOV.COM] Java IO: InputStream</a></li>
</ul>


 </div>
 
 </article></div>

YABOONG

개요
어댑터 패턴에 대해서 알아본다.
Coursera 의 디자인패턴 강의
를 기반으로 작성했다.
Rectangle vs LegacyRectangle, Duck vs Turkey 같은 터무니 없는 예제가 아닌 조금 더 실질적인 예제를 사용해본다.
JDK 에 사용된 어댑터 패턴을 살펴본다.
어댑터 패턴
어댑터 패턴은 이름대로 어댑터처럼 사용되는 패턴이다. 220V 를 사용하는 한국에서 쓰던 기기들을, 어댑터를 사용하면 110V 를 쓰는곳에 가서도 그대로 쓸 수 있다.
이처럼, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해주는 패턴이 어댑터 패턴이라고 할 수 있겠다.
이를 위해 어댑터 역할을 하는 클래스를 새로 만들어야 한다.
기존에 있는 시스템에 새로운 써드파티 라이브러리가 추가된다던지, 
레거시 인터페이스를 새로운 인터페이스로 교체하는 경우에 코드의 재사용성을 높일 수 있는 방법이 어댑터 패턴을 사용하는 것이다.
구조를 보면 아래와 같다.
Client 
써드파티 라이브러리나 외부시스템을 사용하려는 쪽이다.
Adaptee 
써드파티 라이브러리나 외부시스템을 의미한다.
Target Interface 
Adapter 가 구현(implements) 하는 인터페이스이다. 클라이언트는 Target Interface 를 통해 Adaptee 인 써드파티 라이브러리를 사용하게 된다.
Adapter 
 
Client 와 Adaptee 중간에서 호환성이 없는 둘을 연결시켜주는 역할을 담당한다.
Target Interface 를 구현하며, 클라이언트는 Target Interface 를 통해 어댑터에 요청을 보낸다.
어댑터는 클라이언트의 요청을 Adaptee 가 이해할 수 있는 방법으로 전달하고, 처리는 Adaptee 에서 이루어진다.
어댑터 패턴 호출 과정
클라이언트에서는 Target Interface 를 호출하는 것 처럼 보인다.
하지만 클라이언트의 요청을 전달받은 (Target Interface 를 구현한) Adapter 는 자신이 감싸고 있는 Adaptee 에게 실질적인 처리를 위임한다.
Adapter 가 Adaptee 를 감싸고 있는 것 때문에 Wrapper 패턴이라고도 불린다.
어댑터 패턴 사용예제
Coursera 의 디자인 패턴 강의 중 어댑터 패턴에 나오는 예제를 조금 수정해서 구현해 보려한다.
이해를 돕기위해 어댑터 패턴의 설명에 불필요하다고 생각하는 메소드와 코드는 제거했다.
위에서 Client, Target Interface, Adapter, Adaptee 가 나오는 다이어그램을 그대로 구현한 코드다.
UML 을 그려보면 아래와 같다.
헷갈리지 않도록 위 그림과 코드에 사용되는 클래스들을 간단히 설명하면,
그림1
      그림3
      코드
    
Client
      WebClient
      AdapterDemo
    
Target Interface
      WebRequester
      WebRequester
    
Adapter
      WebAdapter
      WebAdapter
    
Adaptee
      WebService
      FancyRequester
    
시나리오는 다음과 같다.
기존에는 WebClient 에서는 요청에 대한 처리로 doWork() 메소드를 호출하는데, 이 처리는 WebRequester 인터페이스를 구현한 OldWebRequester 에게 위임하도록 되어있다.
이때, WebRequester 인터페이스를 구현한 OldWebRequester 의 requestHandler() 를 호출한다.
하지만 이 OldWebRequester 를 써드파티 라이브러리인 FancyRequester 로 변경해야하는 상황이 생겼다고 가정하자.
이때 어댑터 패턴을 적용하여 기존의 코드와 써드파티 라이브러리 어느쪽도 수정하지 않고 FancyRequester 를 적용할 수 있다.
코드를 보자.
WebRequester «Interface»
public interface WebRequester {
    void requestHandler();
}
Target Interface 이다. 구현체를 가지지 않고 requestHandler() 메소드에 대한 정의만 되어있다.
WebClient
public class WebClient {
    private WebRequester webRequester;
    public WebClient(WebRequester webRequester) {
        this.webRequester = webRequester;
    }
    public void doWork() {
        webRequester.requestHandler();
    }
}
doWork() 는 WebRequester 인터페이스를 구현한 클래스의 requestHandler() 메소드를 호출하여 동작한다.
OldWebRequester
public class OldWebRequester implements WebRequester {
    @Override
    public void requestHandler() {
        System.out.println("OldWebRequester is working");
    }
}
시나리오상에서, 기존에 사용하고 있던 WebRequester 의 구현클래스로써, WebClient 에서 doWork() 를 호출하면 내부에서 호출되던 녀석이다.
설명의 편의를 위해 작성했을 뿐, 이 예제의 Client 에서는 사용되지 않는다.
FancyRequester
public class FancyRequester {
    public void fancyRequestHandler() {
        System.out.println("Yay! fancyRequestHandler is called!");
    }
}
사용할 써드파티 라이브러리인 FancyRequester 이다. Adaptee 가 되겠다.
WebAdapter
public class WebAdapter implements WebRequester {
    private FancyRequester fancyRequester;
    public WebAdapter(FancyRequester fancyRequester) {
        this.fancyRequester = fancyRequester;
    }
    @Override
    public void requestHandler() {
        fancyRequester.fancyRequestHandler();
    }
}
어댑터를 위와같이 작성해준다.
WebAdapter 는 Target Interface 인 WebRequester 인터페이스를 구현하고, 인스턴스 생성시 FancyRequester 클래스를 주입한다. 
(FancyRequester 는 보통 또다른 어떤 인터페이스를 구현한 클래스이겠지만, 굳이 또 만들면 이해하기 복잡해지니까 그냥 구현 클래스만 언급했다)
그리고 Target Interface 인 WebRequester 인터페이스의 requestHandler() 를 구현하는데, 
이때 주입시킨 FancyRequester 의 fancyRequestHandler() 메소드를 호출하도록 만든다.
이렇게 하면 WebAdapter 도 WebRequester 인터페이스를 구현했으므로, WebRequester 인터페이스의 구현체를 받아 동작하던 WebClient 에 WebAdapter 를 넘겨줄 수 있고,
기존에 WebClient 에서 requesterHandler() 메소드를 호출하던 코드는 그대로 두면서도,
WebAdapter 의 requestHandler() 를 통해 써드파티 라이브러리인 FancyRequester 를 사용할 수 있게 된다.
실행
public class AdapterDemo {
    public static void main(String[] args) {
        WebAdapter adapter = new WebAdapter(new FancyRequester());
        WebClient client = new WebClient(adapter);
        client.doWork();
    }
}
위 예제 코드로 실행해보면 FancyRequester 가 동작하는 것을 확인할 수 있다.
WHY
애초에 두개의 인터페이스가 달라서 호환이 안된다면, 하나를 바꿔서 되게 하던지, 아니면 둘다 바꾸면 되지 않나?
예제에서는 이해를 돕기위해 FancyRequester 를 인터페이스를 만들지도 않았고 클래스 내부도 훤히 들여다 볼 수 있다.
하지만, FancyRequester 가 오픈소스가 아니라 미리 컴파일된 클래스 바이너리 파일만을 제공받은 써드파티 라이브러리라면 직접적인 접근이 불가능 할 수 있다.
직접적으로 접근할 수 있는 경우라 하더라도 Adaptee 쪽에서 우리가 변경한 코드로 인해 라이브러리나 벤더쪽 시스템 전체가 깨질 수도 있다.
그러면 우리쪽 인터페이스를 수정하면 되지 않나?
가능할 수 있다. 하지만 바꾸려는 우리쪽 인터페이스를 우리 시스템의 다른 어딘가에서 사용하고 있다면? 그 부분도 수정해줘야 한다.
우리쪽 인터페이스를 수정하고, 이에 영향을 받는 부분들을 수정하다가 예기치 못한 오류가 발생할 가능성이 매우 크다.
JDK 에 사용된 어댑터 패턴
어댑터 패턴이 적용된 가장 대표적인 예가 자바의 InputStreamReader 이다.
콘솔에서 입력을 받을 때 아래와 같이 사용하는 것을 본 적이 있을 것이다. (알고리즘 문제풀때 자바로 하면 Scanner 클래스를 사용하지 않고 이렇게 많이 했던 것 같다)
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
BufferedReader 클래스를 까서 위 구문이 실행될때 사용되는 생성자를 보면 아래와 같이 Reader 타입을 받는다.
public BufferedReader(Reader in) {
    this(in, defaultCharBufferSize);
}
하지만 System.in 은 InputStream 타입을 반환한다.
public final static InputStream in = null;
자바의 InputStream 은 바이트 스트림을 읽어들인다. 하지만, BufferedReader 는 캐릭터인풋 스트림을 읽어들인다.
둘은 호환되지 않는다. 하지만, 이 둘을 연결시켜 주는 어댑터가 InputStreamReader 클래스이다.
UML 로 보면 아래와 같은 구조다.
BufferedReader 클래스는 Reader 클래스를 상속받는다. (Reader 클래스는 Readable 인터페이스를 구현한 추상클래스이다),
InputStreamReader 클래스도 Reader 클래스를 상속받는다.
둘 다 Reader 클래스의 서브클래스 이므로 Reader 타입으로 레퍼런스 할 수 있다.
그리고 InputStreamReader 클래스는 InputStream 타입을 받을 수 있는 생성자를 가지고 있으므로,
System.in 을 InputStreamReader 인스턴스 생성시 넘겨주는 방식이다.
InputStreamReader 클래스를 Adapter, System.in 을 Adaptee, Reader 를 Target Interface 라고 할 수 있겠다.
어댑터 패턴 정리
Adaptee 를 감싸고, Target Interface 만을 클라이언트에게 드러낸다.
Target Interface 를 구현하여 클라이언트가 예상하는 인터페이스가 되도록 Adaptee 의 인터페이스를 간접적으로 변경한다.
Adaptee 가 기대하는 방식으로 클라이언트의 요청을 간접적으로 변경한다.
호환되지 않는 우리의 인터페이스와 Adaptee 를 함께 사용할 수 있다.
결론
사용해야하는 인터페이스가 현재의 시스템과 호환되지 않는다고 해서 현재의 시스템을 변경을 해야하는 것은 아니다.
참고한 자료
[Coursera - University of Alberta] Design Patterns 2.1.6 - Adapter Pattern
[HowToDoInJava] Adapter Design Pattern in Java
[JENKOV.COM] Java IO: InputStream

디자인패턴 - 어댑터 패턴

댓글