[디자인 패턴] 구조 패턴 - 어댑터 패턴

구조 (Structure) 패턴

구조 패턴 이란 객체 간의 상호 작용에 대한 구조적 관계를 명확히 정의하여, 코드의 유연성과 재사용성을 높이는 디자인 패턴

 

주요 패턴으론 다음 사항들이 있다.

• 어댑터 (Adapter) <- 이번 글에서 다룰 내용
• 데코레이터(Decorator)
• 복합자(Composite)
• 파셔드(Facade)
• 플라이웨잇(Flyweight)
• 프록시(Proxy)
• 브릿지(Bridge)

 

어댑터 (Adapter) 패턴 이란

서로 호환되기 힘든 인터페이스를 지닌 클래스들이 함꼐 동작할 수 있도록 하는 구조적 패턴

 

아래 예시 처럼 자동차를 레일에서도 다를 수 있도록 어댑터 를 구성하는 패턴

https://refactoring.guru/images/patterns/content/adapter/adapter-ko-2x.png

 

등장 배경

얻은 데이터 (xml)을 분석툴(json 데이터에만 동작)에 넣고 싶음

어댑터가 필요 !

https://refactoring.guru/images/patterns/diagrams/adapter/solution-ko-2x.png

 

구조

1. Client 클래스 : 기존 비즈니스 로직을 포함 하고 있는 클래스 (main)

2. Client Interface : 클라이언트들이 따라야 하는 인터페이스 프로토콜

3. Service 클래스 : specialData를 Input 으로 작동 하는 의 serviceMethod() 가 존재

4. Adapter 클래스 : 클라이언트와 서비스 양쪽에서 작동할 수 있는 클래스로, Service 객체를 래핑

5. Adapter는 method() 함수 : data를 받아 specialData로 리턴해주는 convertToServiceFormat() 함수를 포함

 

https://refactoring.guru/images/patterns/diagrams/adapter/structure-object-adapter-indexed-2x.png

 

장단점

 

장점

• 단일 책임 원칙(SRP) : 데이터 변환 코드를 어댑터에 위임. 기존의 클래스 객체의 책임이 보존
• 개방/폐쇄 원칙(OCP) : 어댑터를 통해 확장(Open)은 적극적(어떻게든 어댑터에서 맞춤), 기존 Service 클래스 수정도 필요 없음

 

단점

• 새로운 인터페이스(Client Interface)와 Adapter 클래스 세트를 도입ㅎ야 함
• 변환해주는 비즈니스 로직.. 코드.. 복잡성 증가 (억지스럽게 맞추려는 면도 있지)

 

다른 패턴과의 관계

vs (구조 패턴) Bridge

• Adapter는 기존앱에 호환되지 않는 일부 클래스가 함께 잘 작동 하도록 만드는 것 (유지 보수의 목적)
• Bridge: 사전에 애플리케이션 일부를 서로 독립적으로 설계 개발 하는데 사용

 

vs (구조 패턴) Decorator, Proxy

• Adapter : 기존 개체에 액세스하기 위해 완전히 새로운(다른) 인터페이스를 제공
• Decorator : 인터페이스를 동일하게 유지되거나 확장 
• Proxy : Proxy를 사용하면 인터페이스가 동일하게 유지
• In/Out Schema 에 대한 관점

 

vs (구조 패턴) Facade

• Adapter : 일반적으로 하나의 객체만 래핑
• Facade : 객체의 전체 하위 시스템과 함께 작동하며, 기존 객체에 대한 새로운 인터페이스를 정의
• 쉽게 말해 많은 하위 객체, 들에 쉽게 접근 할 수 있도록 단순한 인터페이스를 제공한다.

 

vs 데코레이터, 어댑터, 퍼사드

• 어댑터 : 하나의 인터페이스를 다른 인터페이스로 변환
• 데코레이터 : 인터페이스는 바꾸지 않고, 책임(기능)만 추가
• 퍼사드 : 인터페이스를 보다 간단하게 변경