예제로 이해하는 어댑터 패턴

의도

클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변환합니다. 어댑터 패턴은 인터페이스가 호환되지 않아 함께 동작할 수 없던 클래스들이 함께 동작하게 해 줍니다. Gang of Four(GoF) 책의 일곱 가지 구조 패턴 중 하나입니다.

해결하는 문제

쇼핑몰 코드는 작은 PaymentGateway 인터페이스로 동작합니다. charge(amountCents, currency)가 ok 플래그와 거래 ID를 담은 결과를 반환합니다. 그런데 회사가 SDK 모양이 완전히 다른 결제 업체와 계약했습니다. 금액은 십진수 문자열이고, 통화는 요청 객체의 일부이며, 오류는 숫자 상태 코드로 돌아옵니다.

SDK는 바꿀 수 없고, 새 모양에 맞추려고 모든 호출부를 다시 쓰고 싶지도 않습니다. SDK의 스타일이 결제, 환불, 보고서 코드까지 번지면 나중에 업체를 바꿀 때 비용이 큽니다. 어댑터는 번역을 한 클래스에 가둡니다.

구조와 참여자

TypeScript 구현

// Target: what our code expects.
interface PaymentGateway {
  charge(amountCents: number, currency: string): { ok: boolean; id: string };
}

// Adaptee: a third-party SDK we cannot change.
class LegacyPayClient {
  makePayment(req: { amount: string; curr: string }): { status: number; ref: string } {
    return { status: req.curr === "USD" ? 200 : 422, ref: `TX-${req.amount}` };
  }
}

// Adapter: implements the Target by translating to the Adaptee.
class LegacyPayAdapter implements PaymentGateway {
  constructor(private client: LegacyPayClient) {}

  charge(amountCents: number, currency: string) {
    const res = this.client.makePayment({
      amount: (amountCents / 100).toFixed(2),
      curr: currency.toUpperCase(),
    });
    return { ok: res.status === 200, id: res.ref };
  }
}

// Client code knows nothing about LegacyPayClient.
function checkout(gateway: PaymentGateway, totalCents: number): string {
  const result = gateway.charge(totalCents, "usd");
  return result.ok ? `paid ${result.id}` : "payment failed";
}

console.log(checkout(new LegacyPayAdapter(new LegacyPayClient()), 1250)); // paid TX-12.50

나중에 다른 업체로 바꾸려면 어댑터를 하나 더 작성하면 됩니다. checkout과 다른 모든 호출부는 그대로이며, 테스트에서는 가짜 PaymentGateway를 넘길 수 있습니다.

객체 어댑터와 클래스 어댑터

GoF 책은 두 가지 형태를 설명합니다.

TypeScript와 JavaScript에서는 함수를 적응시키는 것만으로 충분한 경우가 많습니다. Node.js에는 이런 종류의 작은 어댑터가 들어 있습니다. util.promisify()는 콜백 스타일 함수를 프로미스를 반환하는 함수로 바꿔 줍니다.

import { promisify } from "node:util";

// Adaptee: old callback style (error first, then result).
function readConfig(name: string, cb: (err: Error | null, value?: string) => void): void {
  setTimeout(() => cb(null, `config for ${name}`), 10);
}

// Adapted: the same function, now with a promise-based interface.
const readConfigAsync = promisify(readConfig);
console.log(await readConfigAsync("app")); // config for app

언제 쓰고 언제 쓰지 말아야 하나

다음과 같을 때 어댑터 패턴을 사용합니다.

• 기존 클래스를 쓰고 싶지만 그 인터페이스가 코드가 필요로 하는 것과 맞지 않을 때.
• 서드파티 라이브러리나 레거시 시스템을 통합하면서 그 API를 프로그램의 가장자리에 가두고 싶을 때.
• 두 결제 업체처럼 서로 다른 여러 구현을 하나의 인터페이스 뒤에 두고 싶을 때.

다음 경우에는 피하세요.

• 양쪽 모두 직접 소유하고 있을 때. 번역 계층을 추가하는 것보다 한쪽 인터페이스를 바꾸는 편이 대개 더 간단합니다.
• adaptee가 실제로 지원할 수 없는 target 인터페이스의 큰 부분을 어댑터가 흉내 내야 할 때. 실제 불일치를 해결하는 대신 숨기게 됩니다.

실제 사용 사례

• Node.js: util.promisify()는 콜백 기반 함수를 프로미스에 맞게 적응시킵니다.
• Java: Arrays.asList()는 배열을 List 인터페이스로 쓸 수 있게 하고, InputStreamReader는 바이트 기반 InputStream을 문자 기반 Reader로 읽을 수 있게 합니다.
• 데이터베이스 라이브러리와 ORM은 데이터베이스마다 어댑터나 드라이버를 하나씩 두므로, 같은 쿼리 API가 PostgreSQL, MySQL, SQLite에서 동작합니다.
• 프런트엔드 코드는 같은 이유로 브라우저 API나 분석 SDK를 프로젝트 전용 작은 인터페이스 뒤에 감싸는 경우가 많습니다.

관련 패턴