Adapter перекладає інтерфейс одного класу в інтерфейс, який очікує ваш код, щоб несумісні компоненти могли працювати разом.
Яку проблему вирішує
Стороння бібліотека чи зовнішнє API майже завжди має свій інтерфейс, який не збігається з тим, що використовує ваша бізнес-логіка. Підлаштовувати весь код під чужий SDK - означає прив'язатися до нього й переписувати все при зміні провайдера.
Як вирішує
Ви описуєте власний контракт, а адаптер реалізує його, всередині викликаючи чужий код і перекладаючи виклики у потрібний формат. Бізнес-логіка працює лише з вашим контрактом.
interface PaymentGateway
{
public function charge(int $amount, string $currency): string;
}
class StripeClient
{
public function pay(array $payload): array
{
return ['id' => 'ch_123'];
}
}
class StripeAdapter implements PaymentGateway
{
public function __construct(private StripeClient $client) {}
public function charge(int $amount, string $currency): string
{
$result = $this->client->pay([
'amount' => $amount,
'currency' => $currency,
]);
return $result['id'];
}
}
StripeAdapter перекладає наш контракт PaymentGateway у виклики SDK Stripe. Якщо завтра прийде інший процесинг, ми напишемо новий адаптер, а решта коду не зміниться.
Де застосовувати
- Платіжні шлюзи, логери, зовнішні API, легасі-код із незручним інтерфейсом.
- Скрізь, де треба підмінювати провайдерів за єдиним контрактом.
Плюси та мінуси
- + Ізолює бізнес-логіку від чужих інтерфейсів - провайдер міняється без правок ядра.
- + Дозволяє підключити несумісний код, не торкаючись його.
- − Додатковий шар класів і перекладу.
- − Надлишковий, якщо ви контролюєте обидва боки й можете відразу узгодити інтерфейси; адаптер потрібен саме для чужого коду, який не можна змінити.
