디자인패턴 구조편의 시작이다.
Adapter Pattern
사용자가 기대하는 다른 인터페이스로 변환하는 패턴으로, 호환성이 없는 인터페이스 때문에 함께 동작할 수 없는 클래스들이 함께 작동하도록 해주는 패턴(위키피디아)
말로는 이해가 되지 않는다.
-
클라이언트가 Target을 바라보고 있다.
-
Target을 Adapter가 구현하고 , 들어온 요청을 Adapter이 Adaptee에게 위임한다.
그림을 보면 흐름은 대충 이해가 간다.
실제 코드로 한번 사진을 구현해보자.
public interface Target{
void request();
}
public class Adapter implements Target{
private Adaptee adaptee;
public Adapter(Adaptee Adaptee){
this.adaptee = adaptee;
}
@Override
public void request(){
adaptee.specificRequest();
}
}Adapter클래스는 Target을 구현한다.
그리고 메소드 내부에서 adaptee에게 위임한다.
public interface Adaptee{
void specificRequest();
}@Slf4j
public class AdapteeConcrete implements Adaptee{
public void specificRequest(){
log.info("specificRequest 호출");
}
}
이제 클라이언트 측을 살펴보자.
Target adapter = new Adapter(new AdapteeConcrete());
adapter.request();
//request호출시 -> AdapteeConcrete의 specificRequest가 내부적으로 호출
코드상으로 적어보면 이런 패턴을 의미한다.
사용하는 이유
결국 어댑터 패턴이라는 것은 모든 것을 하나의 인터페이스로 추상화하기 힘들기 때문에 사용한다고 한다.
기존에 사용하던 라이브러리(Adaptee)를 여러 코드에서 참고하여 사용하고 있다고 가정해보자.
그러던 와중 특정 부분에서 더 이상 해당 라이브러리가 맞지 않아 라이브러리를 수정하게 된다면 , 참조하던 모든 곳에서 에러가 발생할 것이다.
이 때 중간에 어댑터 역할의 클래스를 두면 , 기존의 라이브러리 로직은 그대로 두고 , request 메소드 부분에 추가되는 내용을 구현해주면 기존 라이브러리를 손대지 않고 수정할 수 있다.
장점
- 기존 코드를 변경하지 않아도 된다.
디자인 패턴은 비슷비슷한것 같다.
그래서 의도를 아는 것이 중요하다고 하는데 , 의도를 봐도
데코레이터 패턴, 프록시 패턴등과 너무 비슷하다.
추후에 프록시 ,데코레이터등을 공부해보고 , 다시 정리해야겠다.
참고
https://jusungpark.tistory.com/22
https://ko.wikipedia.org/wiki/%EC%96%B4%EB%8C%91%ED%84%B0_%ED%8C%A8%ED%84%B4
https://yaboong.github.io/design-pattern/2018/10/15/adapter-pattern/
