Deep Dive Into Design Patterns - 어댑터 패턴

💡 어댑터 패턴이란?

호환되지 않는 인터페이스를 가진 객체들이 협업할 수 있도록 하는 구조적 디자인 패턴입니다.

 

📌 문제 상황

주식 시장 모니터링 앱을 만들고 있고, 이 앱은 여러 소스에서 주식 데이터를 XML 형식으로 다운로드한 후 사용자에게 보기 좋은 차트들과 다이어그램들을 표시한다고 상상해 봅시다.

 

어느 시점에 당신은 타사의 스마트 분석 라이브러리를 통합하여 당신의 앱을 개선하기로 결정했습니다. 그런데 이 분석 라이브러리는 JSON 형식의 데이터로만 작동합니다. 즉, 앱과 라이브러리가 호환되지 않는 상황입니다.

이 라이브러리를 XML과 작동하도록 변경할 수 있으나, 그러면 라이브러리에 의존하는 일부 기존 코드가 손상될 수 있습니다. 또 처음부터 타사의 라이브러리 소스 코드에 접근하는 것이 불가능하여 위의 해결 방식을 사용하지 못할 수도 있습니다.

 

📌 그래서, 어댑터 패턴을 씁니다.

이 경우에 쓰이는 패턴이 ‘어댑터 패턴’입니다. 어댑터는 한 객체의 인터페이스를 다른 객체가 이해할 수 있도록 변환하는 특별한 객체입니다.

 

어댑터는 변환의 복잡성을 숨기기 위하여 객체 중 하나를 래핑(포장)합니다. 래핑된 객체는 어댑터를 인식하지도 못합니다. 예를 들어 미터 및 킬로미터 단위로 작동하는 객체를 모든 데이터를 피트 및 마일과 같은 영국식 단위로 변환하는 어댑터로 래핑할 수 있습니다.

 

어댑터는 데이터를 다양한 형식으로 변환할 수 있을 뿐만 아니라 다른 인터페이스를 가진 객체들이 협업하는 데에도 도움을 줄 수 있습니다.

 

📌 어댑터는 어떻게 작동하는데?

1. 어댑터는 기존에 있던 객체 중 하나와 호환되는 인터페이스를 받습니다.
2. 이 인터페이스를 사용하면 기존 객체는 어댑터의 메서드들을 안전하게 호출할 수 있습니다.
3. 호출을 수신하면 어댑터는 이 요청을 두 번째 객체에 해당 객체가 예상하는 형식과 순서대로 전달합니다.

때로는 양방향으로 호출을 변환할 수 있는 양방향 어댑터를 만드는 것도 가능합니다.

위의 그림처럼 호환되지 않는 경우, XML → JSON 변환 어댑터를 만들고 이 어댑터를 통해서만 해당 라이브러리와 통신하도록 코드를 조정합니다. 어댑터는 호출을 받으면 들어오는 XML 데이터를 JSON 구조로 변환한 후 해당 호출을 래핑된 분석 객체의 절절한 메서드들에 전달합니다.

 

💡 클래스 다이어그램으로 본 어댑터 패턴

어댑터 패턴은 클라이언트, 클라이언트 인터페이스, 서비스, 어댑터로 구성되며 1) 합성 2) 상속 두 방법으로 구현할 수 있습니다.

📌 합성을 사용한 어댑터 = 객체 어댑터(Object Adaptor)

1. 클라이언트는 프로그램의 기존 비즈니스 로직을 포함하는 클래스입니다. → 쉽게 말하면, 기존 시스템을 어댑터를 통해 이용하려는 부분으로, Client Interface를 통해 서비스를 이용합니다.
2. 클라이언트 인터페이스(타겟)는 다른 클래스들이 클라이언트 코드와 공동 작업할 수 있도록 따라야하는 프로토콜을 뜻합니다. → 쉽게 말하면, Adapter가 구현하는 인터페이스를 말합니다.
3. 서비스(Adaptee)는 일반적으로 타사 또는 레거시의 유용한 클래스를 뜻합니다. → 쉽게 말하면, Adapter의 대상 객체로, 클라이언트와 호환이 안되지만 사용하고 싶은 객체를 말합니다.
4. 어댑터는 클라이언트와 서비스 양쪽에서 작동할 수 있는 클래스로, 서비스 객체를 래핑하는 동안 클라이언트 인터페이스를 구현합니다.

클라이언트 코드는 클라이언트 인터페이스를 통해 어댑터와 작동하는 한 어댑터 클래스와 결합하지 않습니다. 덕분에 기존 클라이언트 코드 수정 없이 새로운 유형의 어댑터들을 프로그램에 도입할 수 있습니다. 이것은 서비스 클래스의 인터페이스가 변경되거나 교체될 때 유용할 수 있습니다.

 

객체 어댑터의 가장 큰 특징은 ‘위임’을 사용한다는 것입니다.

 

⭐ 상속(Inheritance) VS 합성(Composition) VS 위임(Delegation)

상속은 is a 관계로 extends 키워드를 통해 부모의 속성들을 자식이 물려받아서 사용할 수 있도록 하는 관계이다. 부모의 속성을 물려받기 때문에, 자식은 부모의 코드를 작성하지 않고 사용함으로써 구현하기가 수월해진다.
- 상속을 이용하면 중복 코드를 작성하지 않는다는 장점이 있지만, 이로 인해 부모 클래스와 강한 결합도를 가지게 됨으로써 변화에 대응하기가 어려워진다. (OCP 원칙 위배)
- 부모의 속성들을 모두 사용하지 않는 경우에 상속을 사용하면 유지보수가 어려워진다. (LSP 위배)

합성은 has a 관계로 한 클래스가 다른 클래스를 인스턴스 변수로 가지고 있는 상태이다.
- 상속에 비해 결합이 느슨하다. 그러나 상속에 비해 중복 코드가 많아진다. (DRY = Do Not Repeat Yourself, SW 개발 원칙 위배)

위임은 uses a 관계로 클래스 내에서 위임 관계에 있는 클래스의 인스턴스를 가지고 있는 상태이다. 다시 말해, Composition과 Forwarding을 합쳤다고 볼 수 있다. 상속이 클래스 사이의 관계라면, 위임은 인스턴스 사이의 관계이다.
- 상속 관계는 정적인 관계로 컴파일 시간에 모든 관계가 정해지고 변경될 수 없지만, 위임 관계는 동적인 관계로 런타임 시간 동안 관계가 변경될 수 있다.

 

[예제 코드]

// Adaptee : 클라이언트에서 사용하고 싶은 기존의 서비스 (하지만 호환이 안되서 바로 사용 불가능)
class Service {

    void specificMethod(int specialData) {
        System.out.println("기존 서비스 기능 호출 + " + specialData);
    }
}

// Client Interface : 클라이언트가 접근해서 사용할 고수준의 어댑터 모듈
interface Target {
    void method(int data);
}

// Adapter : Adaptee 서비스를 클라이언트에서 사용하게 할 수 있도록 호환 처리 해주는 어댑터
class Adapter implements Target {
    Service adaptee; // composition으로 Service 객체를 클래스 필드로

    // 어댑터가 인스턴스화되면 호환시킬 기존 서비스를 설정
    Adapter(Service adaptee) {
        this.adaptee = adaptee;
    }

    // 어댑터의 메소드가 호출되면, Adaptee의 메소드를 호출하도록
    public void method(int data) {
        adaptee.specificMethod(data); // 위임
    }
}
출처: <https://inpa.tistory.com/entry/GOF-💠-어댑터Adaptor-패턴-제대로-배워보자#어댑터_패턴_구조> [Inpa Dev 👨‍💻:티스토리]

class Client {
    public static void main(String[] args) {
        // 1. 어댑터 생성 (기존 서비스를 인자로 받아 호환 작업 처리)
        Target adapter = new Adapter(new Service());

        // 2. Client Interfac의 스펙에 따라 메소드를 실행하면 기존 서비스의 메소드가 실행된다.
        adapter.method(1);
    }
}
출처: <https://inpa.tistory.com/entry/GOF-💠-어댑터Adaptor-패턴-제대로-배워보자#어댑터_패턴_구조> [Inpa Dev 👨‍💻:티스토리]

 

📌 상속을 사용한 어댑터 = 클래스 어댑터(Class Adaptor)

객체 어댑터와 구성은 동일하지만, 구현 방식이 다릅니다. ‘상속’을 이용해 구현하기 때문에, 객체 구현 없이 바로 코드 재사용이 가능합니다. 그러나 자바에서는 다중 상속이 안되므로 보통 implements, extends 하여 구현합니다.

// Adaptee : 클라이언트에서 사용하고 싶은 기존의 서비스 (하지만 호환이 안되서 바로 사용 불가능)
class Service {

    void specificMethod(int specialData) {
        System.out.println("기존 서비스 기능 호출 + " + specialData);
    }
}

// Client Interface : 클라이언트가 접근해서 사용할 고수준의 어댑터 모듈
interface Target {
    void method(int data);
}

// Adapter : Adaptee 서비스를 클라이언트에서 사용하게 할 수 있도록 호환 처리 해주는 어댑터
class Adapter extends Service implements Target {

    // 어댑터의 메소드가 호출되면, 부모 클래스 Adaptee의 메소드를 호출
    public void method(int data) {
        specificMethod(data);
    }
}
출처: <https://inpa.tistory.com/entry/GOF-💠-어댑터Adaptor-패턴-제대로-배워보자#어댑터_패턴_구조> [Inpa Dev 👨‍💻:티스토리]

class Client {
    public static void main(String[] args) {
        // 1. 어댑터 생성
        Target adapter = new Adapter();

        // 2. 인터페이스의 스펙에 따라 메소드를 실행하면 기존 서비스의 메소드가 실행된다.
        adapter.method(1);
    }
}
출처: <https://inpa.tistory.com/entry/GOF-💠-어댑터Adaptor-패턴-제대로-배워보자#어댑터_패턴_구조> [Inpa Dev 👨‍💻:티스토리]

 

💡 마무리

어댑터 패턴은

1. 기존 클래스를 사용하고 싶지만 그 인터페이스가 나머지 코드와 호환되지 않을 때
2. 이미 만든 것을 재사용하고자 하나 이 재사용 가능한 라이브러리를 수정할 수 없을 때
3. 자식 클래스에 기능을 추가하고 싶지만 부모 클래스에는 추가하기 어려울 때

에 사용할 수 있습니다.

 

SRP와 OCP를 만족할 수 있는 반면, 다수의 새로운 인터페이스와 클래스들을 도입해야 하므로, 코드의 전반적인 복잡성이 증가합니다.

 

 

어댑터 패턴

 

💠 어댑터(Adaptor) 패턴 - 완벽 마스터하기