Bridge розділяє абстракцію та її реалізацію на дві окремі ієрархії, щоб змінювати їх незалежно.
Яку проблему вирішує
Коли є кілька незалежних вимірів варіативності, наївний підхід множить класи комбінаторно. Приклад - канали сповіщення (email, SMS, push) × формати повідомлень (JSON, текст, HTML). Без Bridge довелось би писати EmailJsonNotifier, EmailPlainNotifier, SmsJsonNotifier… - добуток обох вимірів.
Як вирішує
Один вимір лишається в основній ієрархії (канали), а другий виноситься в окрему залежність (Formatter), яку передають усередину. Канали і формати тепер комбінуються вільно: 3 + 2 класи замість 3 × 2.
interface Formatter
{
public function format(string $message): string;
}
class JsonFormatter implements Formatter
{
public function format(string $message): string
{
return json_encode(['message' => $message]);
}
}
class PlainFormatter implements Formatter
{
public function format(string $message): string
{
return $message;
}
}
abstract class NotifierBridge
{
public function __construct(protected Formatter $formatter) {}
abstract public function send(string $message): void;
}
class EmailNotifierBridge extends NotifierBridge
{
public function send(string $message): void
{
$body = $this->formatter->format($message);
// send email
}
}
class SmsNotifierBridge extends NotifierBridge
{
public function send(string $message): void
{
$body = $this->formatter->format($message);
// send sms
}
}
Де застосовувати
- Дві (або більше) незалежні осі варіативності, які множаться комбінаторно: канал × формат, рендерер × платформа, драйвер × протокол.
- Коли треба додавати нові варіанти кожної осі окремо.
Плюси та мінуси
- + Лінійне зростання класів замість комбінаторного.
- + Осі розвиваються незалежно, без знання одна про одну.
- − Зайва абстракція, якщо вимір варіативності насправді один.
- − Різниця з Adapter: Adapter узгоджує вже наявні несумісні інтерфейси постфактум, а Bridge проєктується наперед, щоб дві осі змінювались окремо. Якщо вимір один - вистачить простого інтерфейсу зі стратегіями.
