Структурний патерн проектування «Міст»
Призначення патерну Bridge
У системі можуть існувати класи, відносини між якими будуються відповідно до наступної об'єктно-орієнтованої ієрархії: абстрактний базовий клас оголошує інтерфейс, а конкретні підкласи реалізують його належним чином. Такий підхід є стандартним в ОВП, проте йому властиві такі недоліки:
Система, побудована з урахуванням успадкування, є статичною. Реалізація жорстко прив'язана до інтерфейсу. Змінити реалізацію об'єкта деякого типу у процесі виконання програми вже неможливо.
Система стає важко підтримуваною, якщо кількість споріднених похідних класів стає більшою.
Пояснимо складності розширення системи новими типами з прикладу розробки логгера. Логгер це система протоколювання повідомлень, що дозволяє фіксувати помилки, налагоджувальну та іншу інформацію в процесі виконання програми. Розроблений нами логер може використовуватися в одному з трьох режимів: виводити повідомлення на екран, файл або відсилати їх на віддалений комп'ютер. Крім того, необхідно забезпечити можливість його застосування в одно- та багатопотокових середовищах.
Стандартний підхід на основі поліморфізму використовує таку ієрархію класів.
Видно, що кількість родинних підкласів у системі дорівнює 6. Додавання ще одного виду логера збільшить його до 8, двох – до 10 тощо. Система стає важко керованою.
Зазначені недоліки відсутні в системі, спроектованій із застосуванням патерну Bridge.
Опис патерну Bridge
Паттерн Bridge поділяє абстракцію та реалізацію на дві окремі ієрархії класів так, що їх можна змінювати незалежно один від одного.
Перша ієрархія визначає інтерфейс абстракції, доступний користувачеві. Для випадку проектованого нами логера абстрактний базовий клас Logger міг би оголосити інтерфейс методу log() для виведення повідомлень. Клас Logger також містить покажчик на реалізацію pimpl, який ініціалізується належним чином під час створення логера конкретного типу. Цей покажчик використовується для перенаправлення запитів користувача в реалізацію. Зауважимо, у випадку підкласи ConsoleLogger, FileLogger і SocketLogger можуть розширювати інтерфейс класу Logger.
Усі деталі реалізації, пов'язані з особливостями середовища, ховаються в другій ієрархії. Базовий клас LoggerImpl оголошує інтерфейс операцій, призначених для відправки повідомлень на екран, файл та віддалений комп'ютер, а підкласи ST_LoggerImpl та МT_LoggerImpl його реалізують для однопотокового та багатопотокового середовища відповідно. У загальному випадку, інтерфейс LoggerImpl необов'язково повинен точно відповідати інтерфейсу абстракції. Часто він виглядає як набір низькорівневих примітивів.
Паттерн Bridge дозволяє легко змінити реалізацію під час виконання програми. Для цього достатньо переналаштувати покажчик pimpl на об'єкт-реалізацію потрібного типу. Застосування патерна Bridge також дозволяє скоротити загальну кількість підкласів у системі, що робить її більш простою у підтримці.
Структура патерну Bridge
UML-діаграма класів патерну Bridge
Паттерни Bridge і Adapter мають схожу структуру, проте цілі їх використання різні. Якщопатерн Adapterзастосовують для адаптації вже існуючих класів у систему, патерн Bridge використовується на стадії її проектування.
Реалізація патерну Bridge
Наведемо реалізацію логераіз застосуванням патерну Bridge.