Структурні шаблони проектування - Міст

шаблоны проектирования, Bridge, мост

Голи

• Відокремте абстракцію від її реалізації, щоб вони могли змінюватися незалежно один від одного.
• Створення громадського інтерфейсу в ієрархії наслідування та реалізація у своїй власній ієрархії наслідування.
• Крім інкапсуляції використання ізоляції

Проблеми

"Зміцнення програмних зв'язків" шляхом використання підкласу абстрактного базового класу для забезпечення альтернативних реалізацій. Це блокує прив'язку до часу компіляції між інтерфейсом та реалізацією. Абстракція та реалізація не можуть бути незалежно розширені чи перевизначені.

Мотивація

Розглянемо область "планування потоків".

Існує два типи планувальників потоків, два типи операційних систем або платформи. З огляду на цей підхід до спеціалізації, ми повинні визначити клас для кожного варіанта цих двох варіацій. Якщо ми додамо нову платформу (скажімо… віртуальну машину Java), як би виглядала наша ієрархія?

Що, якщо у нас було три види планувальників потоків та чотири види платформ? Що робити, якщо ми мали п'ять видів планувальників потоків і десять видів платформ? Кількість класів, які ми мали б визначити, є результатом кількості схем планування та кількості платформ.

Шаблон проектування Bridge пропонує рефакторинг цієї експоненційно вибухонебезпечної ієрархії успадкування у дві ортогональні ієрархії – одну для абстракцій, незалежних від платформи, а іншу для залежних від платформи реалізацій.

Обговорення

Розкладіть інтерфейс компонента та реалізацію в ортогональні ієрархії класів. Клас інтерфейсу містить покажчик абстрактний клас реалізації. Цей покажчик ініціалізується екземпляром конкретного класу, проте подальше взаємодія класу інтерфейсу з класом реалізації обмежується абстракцією, підтримуваної у базовому класі реалізації. Клієнт взаємодіє з класом інтерфейсу і, своєю чергою, «делегує» всі запити реалізації класу.

Об'єкт інтерфейсу – це «обробник», відомий та використовуваний клієнтом; у той час як об'єкт реалізації або «тіло» безпечно інкапсульований, щоб гарантувати, що він може продовжувати розвиватися або повністю замінюватись (або використовуватися під час виконання).

Використовуйте шаблон Bridge, якщо:

• Ви хочете, щоб реалізація прив'язувалася в рантаймі
• у вас є зростання кількості класів, що виникають в результаті сполученого інтерфейсу та численних реалізацій,
• Ви хочете розділити реалізацію між кількома об'єктами,
• Вам потрібно зіставити ортогональні ієрархії класів.

Наслідки включають:

• декомпозицій інтерфейсу об'єкта
• покращена розширюваність (ви можете розширити (наприклад, підклас) ієрархії абстракції та реалізації незалежно),
• приховування деталей від клієнтів.

Міст є синонімом ідіоми «обробник/тіло». Це механізм проектування, що інкапсулює клас реалізації всередині класу інтерфейсу. Перший – це тіло, а друге – обробник. Оброблювач розглядається користувачем як фактичний клас, але робота виконується у тілі. «Ідіома класу handle/body може використовуватися для декомпозиції складної абстракції на дрібніші, керованіші класи. Ідіома може відбивати спільне використання одного ресурсу кількома класами, які контролюють доступом до нього (наприклад, підрахунок посилань)».

Структура

Клієнт не хоче мати справу із залежними від платформи деталями. Шаблон Bridge інкапсулює цю складність за абстракційну обгортку.

Bridge підкреслює ідентифікацію та поділ абстракції "інтерфейсу" від абстракції "реалізації".

Приклад

Шаблон Bridge відокремлює абстракцію від її реалізації, так що вони можуть змінюватись незалежно один від одного. Прикладом Моста є побутовий вимикач, що управляє вогнями, стельовими вентиляторами і т. д. Метою перемикача є включення чи вимикання пристрою. Фактично перемикач може бути реалізований як ланцюг, що тягне, простий двопозиційний перемикач або різні диммерні перемикачі.

Контрольний список

1. Вирішіть, чи існують у додатку дві можливі ортогональні ієрархії класів. Ці незалежні ієрархії можуть бути: абстракція/платформа, або домен/інфраструктура, або інтерфейс/інтерфейс, або інтерфейс/реалізація.
2. Розробте поділ проблем: чого хоче клієнт та що надають платформи.
3. Створіть інтерфейс платформи, який мінімальний, необхідний і достатній. Його мета – відокремити абстракцію від платформи.
4. Визначити похідний клас цього інтерфейсу кожної платформи.
5. Створіть базовий клас абстракції, який має об'єкт платформи і делегує йому платформно-орієнтовану функціональність.
6. Визначте спеціалізації класу абстракції, якщо це потрібно.

Емпіричні правила

• Адаптер дозволяє працювати з класами після того, як вони розроблені; Міст змушує їх працювати до того, як вони були розроблені.
• Міст розроблений заздалегідь, щоб абстракція та реалізація змінювалися незалежно. Адаптер модернізує код, щоб класи працювали разом.
• State, Strategy, Bridge (і певною мірою Adapter) мають аналогічні структури рішень. Усі вони поділяють елементи ідіоми «обробник/тіло». Вони різняться за намірами - тобто вирішують різні проблеми.
• Структура State та Bridge ідентична (за винятком того, що Bridge допускає ієрархії класів, тоді як State допускає лише одне). Ці два шаблони використовують одну і ту ж структуру для вирішення різних завдань: State дозволяє змінювати поведінку об'єкта разом з його станом, у той час як намір Моста полягає в тому, щоб відокремити абстракцію від його реалізації, щоб вони могли змінюватись незалежно.
• Якщо інтерфейси класів делегують створення своїх класів реалізації (замість безпосередньо створювати / пов'язувати себе), тоді в проекті зазвичай використовується шаблон Abstract Factory для створення реалізації об'єктів.