목차
개요
이번 글에선 Class/Object Structural Pattern인 어댑터 패턴에 대해 알아보겠습니다.
내용
요약
한 클래스의 인터페이스를 다른 인터페이스로 바꾸자.
예시
주식시장 데이터를 분석하는 앱을 만든다고 생각해봅시다. 먼저 주식시장 데이터를 어디선가 가져와야 합니다. 그 후, 분석 라이브러리를 사용해서 분석을 합니다. 주식시장 데이터와 분석은 모두 third-party에서 이루어집니다. 이 때, 주식시장 데이터는 CSV 포맷으로 제공되고 분석 라이브러리는 JSON만 받는다면 어떻게 해야 할까요? 이렇게 서로 다른 인터페이스를 가지는 라이브러리들을 호환되게 할 수 있는 패턴이 어댑터 패턴입니다.
구조
위 예제를 적용하면, Target은 AnalyzeService, Adaptee는 StockLoader에 해당한다.
객체 어댑터
클래스 어댑터
이야깃거리
언제 써야 할까?
- 기존에 존재하는 클래스를 사용하고 싶은데 필요한 인터페이스에 맞지 않을 때
장단점
- (Pros) 데이터 변환 코드를 따로 분리해 단일 책임 원칙을 지킬 수 있음.
- (Cons) 코드의 복잡성 증가
Case Study
어댑터 패턴은 실무 코드에서도 많이 쓰이고 있습니다.
Case Study 1. Spring HttpWebHandlerAdapter
출처
GoF Design Patterns
https://refactoring.guru/ko/design-patterns/adapter
'Design Patterns' 카테고리의 다른 글
| [Design Patterns] Composite (0) | 2024.03.17 |
|---|---|
| [Design Patterns] Bridge (0) | 2024.03.16 |
| [Design Patterns] Singleton (0) | 2024.02.25 |
| [Design Patterns] Prototype (0) | 2024.02.25 |
| [Design Patterns] Factory Method (1) | 2024.01.27 |