[디자인패턴] Adapter

Adapter Pattern

• 서로 다른 인터페이스를 연결함
• 이미 사용중이거나 정의된 인터페이스를 변경하지 않고 기존에 사용하던대로 사용할 수 있도록 Adapter 객체 제공
• 클라이언트가 사용하던 방식대로 호출하여 사용할 수 있도록 조정
  => 합성과 객체를 속성으로 만들어서 참조
  => ex: JDBC, JRE

합성(Compositon)으로 구현

상속(inheritance)으로 구현

code: 합성 방식의 예제

• Client Interface

public interface Print {

    void printWeek();
    void printStrong();
}

• Adapter

public class PrintBanner implements Print {

    Banner banner; // 해당 클래스를 가져옴, Composite 

    public PrintBanner(String str) {
        banner = new Banner(str);
    }
    // .......... @Override 해야하는 메서드들 가져올 것
}

• Service

public class Banner {
    private String string;

    public Banner(String str) {
        this.string = str;
    }
	//..... 필요한 메서드들 채워서 사용할 것
}

---

장단점

장점
1. 단일책임원칙: 프로그램의 기본 비즈니스 로직에서 인터페이스 또는 데이터 변환 코드를 분리할 수 있음
2. 개방폐쇄원칙: 기존의 클라이언트 코드를 손상시키지 않고 새로운 유형의 어댑터들을 프로그램에 도입할 수 있음
단점

1. 코드의 전반적인 복잡성이 증가

---

정리

어댑터 패턴은 전에 spring mvc패턴을 배울 때 controller에서 핸들러 어댑터를 호출한다는 내용을 배울 때 접한 적이 있다. 단점으로는 새로운 인터페이스와 클래스들을 도입해야 해서 코드의 전반적인 복잡성이 증가한다고 하는데 아직 실무로 어댑터 패턴을 접해본 일은 없어서 그런지 어차피 클라이언트는 인터페이스로 접근해서 구체적인 코드는 알 수 없는게 더 이득이 클 것 같은데 그만큼 코드가 복잡해질 일이 있을까? 하지만 코드에는 무엇 하나만 정답인게 없는 법. 그냥 빨리 실무 들어가서 경험해보는게 좋겠다.

출처

• https://inf.run/9iX5
• https://refactoring.guru/ko/design-patterns/adapter

해당 글은 인프런 박은종 강사님의 강의 내용을 정리하기 위하여 작성하였습니다.