Bridge — разделение абстракции и реализации для независимой эволюции

Bridge разделяет абстракцию и её реализацию на две независимые иерархии, позволяя изменять каждую сторону без влияния на другую. Это делает систему расширяемой, устойчивой к изменениям и удобной для поддержки.

Паттерн особенно полезен, когда существуют разные варианты поведения и разные варианты реализации, которые должны комбинироваться между собой.

Bridge применяется в драйверах, API-слоях, интеграции с инфраструктурой, модульных архитектурах, системах рендеринга, логировании, работе с БД и платформах плагинов.

---

---

Bridge — один из самых фундаментальных структурных паттернов, который позволяет разделить концепцию на «что делаем» и «как делаем». Он создаёт две независимые части:

• Абстракция — интерфейс, отражающий бизнес-логику или смысловую часть.

• Реализация — детали выполнения, инфраструктурные аспекты или конкретные технологии.

Эти части связаны «мостом» (bridge), но могут развиваться независимо.

Когда нужен Bridge

Bridge применяется, когда:

• нужно поддерживать несколько реализаций одной абстракции;

• абстракция и реализация должны меняться независимо;

• требуется возможность расширять систему по двум разным осям;

• нельзя жёстко связывать бизнес-логику с технологией;

• мы проектируем API-слой или архитектуру плагинов.

Часто используется в средах, где есть требования к долгой поддержке и постепенной миграции.

---

Примеры применения Bridge в архитектуре ИС

1. Логирование и мониторинг

Абстракция:

Logger
  - logInfo()
  - logError()

Реализации:

• логирование в файл,

• отправка в ELK,

• отправка в Loki,

• логирование в консоль.

Важный момент: бизнес-слой работает с Logger, не зная, куда реально идут данные.

---

2. Драйверы и устройство ввода/вывода

Абстракция:

• рендеринг изображения,

• печать,

• сетевое подключение.

Реализации:

• OpenGL / Vulkan / DirectX,

• разные модели принтеров,

• TCP / UDP / QUIC.

Bridge позволяет менять реализацию без изменения кода абстракции.

---

3. Работа с базами данных

Абстракция:

• «хранилище заказов»

• «хранилище пользователей»

Реализации:

• PostgreSQL

• Oracle

• MongoDB

• Cloud Firestore

• Redis

Архитектор может менять хранилище, не переписывая бизнес-слой.

---

4. Интеграция с инфраструктурой

Абстракция: сервис уведомлений
Реализации: e-mail, SMS, push, Telegram, WhatsApp.

Bridge позволяет создавать новые каналы без изменения логики отправки.

---

5. Платформы плагинов и расширений

Абстракция:

• интерфейс обработчика событий,

• интерфейс трансформатора данных,

• интерфейс рендера.

Реализация:

• каждый плагин — отдельный компонент.

Bridge обеспечивает слабую связанность.

---

6. API Gateway и адаптация каналов

Абстракция:

• команда «создать заказ»

• команда «проверить лимит»

Реализация:

• REST,

• gRPC,

• SOAP,

• message queue.

Bridge разгружает бизнес-логику от транспортного уровня.

---

Преимущества Bridge

1. Независимость развития абстракции и реализации

Можно менять технологию хранения данных, а бизнес-код останется прежним.

2. Устойчивость к изменениям

Bridge помогает проектировать долгоживущие системы.

3. Снижение связанности

Абстракции остаются чистыми, а реализации изолированы.

4. Расширяемость

Можно вводить новые реализации без модификации существующей архитектуры.

5. Поддержка принципов SOLID

Особенно Open/Closed и Dependency Inversion.

---

Недостатки

• увеличивается количество классов и интерфейсов;

• требует дисциплины дизайна;

• может быть избыточен для простых задач.

Но в архитектуре ИС Bridge используется постоянно именно для долгосрочной устойчивости.

---

Bridge в учебниках и стандартах

Bridge рассматривается как:

• архитектурный механизм отделения бизнес-слоя от платформы,

• способ модульного проектирования,

• ключевой элемент в слоистых и компонентных архитектурах,

• часть проектирования модульных и расширяемых систем.

Bridge там фигурирует в темах:

• архитектура программных систем,

• интерфейсы подсистем,

• абстракции доступа к ресурсам,

• проектирование длинного жизненного цикла ИС.

---

Почему архитектор обязан владеть Bridge

Потому что бизнес-слой не должен зависеть от:

• БД,

• протоколов,

• API сторонних сервисов,

• библиотек,

• платформ.

Bridge — это фундамент чистой архитектуры, многослойных систем, микросервисов, систем с адаптируемыми технологиями и долгоживущих ИС.

Он даёт:

• гибкость,

• переиспользуемость,

• модульность,

• технологическую независимость,

• контроль эволюции архитектуры.

---