3. 이미 고객이 원하는
기능을 담고있는 기
존 클래스가 있어.
이걸 사용할래.
(=Adaptee)
고객이 원하는 인터
페이스
(=Target)
기존 클래스를 고객이 원
하는 인터페이스 형태를
갖도록 만들 거야.
그러기 위해 어댑터 클래
스를 사용해서 기존 클래
스를 감쌀 거야.
(=Adapter)
5. 기존 클래스를 고객이 원
하는 인터페이스 형태를
갖도록 만들 거야.
고객이 원하는 인터
페이스
(=Target)
기존 클래스가 있어.
이걸 사용할래.
(=Adaptee)
어댑터가 인터
페이스를 구현
어댑터가
어댑티를
구현
고객쪽 코드에서
인터페이스 구현체를 사용한
다.
7. 기존 클래스를 고객이 원
하는 인터페이스 형태를
갖도록 만들 거야.
고객이 원하는 인터
페이스
(=Target)
기존 클래스가 있어.
이걸 사용할래.
(=Adaptee)어댑터가 인터
페이스를 구현 어댑터가
어댑티를
가진다.
고객쪽 코드에서
인터페이스 구현체를 사용한
다.
8. 솔직한 후기 - 왜 쓰나요?
어댑터 패턴은 클래스 제공자가 기존의 클래스를 클래스 사용자가 원하는 사용방
법에 맞춰서 제공하려고 할 때 씁니다.
제 경우 클래스 제공자도 저고, 클래스 사용자도 저이기 때문에 그 클래스 사용법에
대해 잘 압니다. 그래서 이런 경우엔 어댑터 패턴을 적용하지 않아도 됩니다.
9. 솔직한 후기 - 왜 쓰나요?
다만, GA와 페북Analytics 같은 비슷한 서드파티 라이브러리를 사용할 때 라이브러
리마다 일관된 사용방법(init(), release(), logEvent())을 유지하기 위해 라이브러리
마다 어댑터 패턴을 적용합니다. 인터페이스까지 정의해서 강제하진 않으므로 완
전한 어댑터 패턴이라고 보긴 어렵습니다. 저는 이런 어댑터 클래스를 Wrapper 클
래스라고도 부릅니다.
장점1. 협업할 때 다른 개발자가 서드파티 라이브러리 한 개의 인터페이스만 이해
하면, 다른 서드파티 라이브러리가 쓰인 코드를 읽을 때 바로 이해할 수 있다.
장점2. 특정 작업을 삽입하고 싶을 때 어댑터 클래스가 인터셉터 역할을 해준다. 이
장점이 매우 큽니다. 실제로 대개 라이브러리는 가공을 해서 사용하게 되는데 가공
코드를 어댑터 클래스에 넣어두면 관심사의 분리, 캡슐화, 쉬운 수정의 이점을 얻습
니다.
