ПАТЕРН

ПРОЕКТУВАННЯ
ПЗ 
BRIDGE
Виконала:
студентка групи ПЗПІ-19-1
Пархоменко Юлія Юріївна
Призначення патерна Bridge

Bridge (міст) – це структурний патерн проектування, який дозволяє відділити

абстракцію від реалізації таким чином, аби і абстракцію, і реалізацію можна
було змінювати незалежно один від одного.

Патерн також відомий як Handle та Body.

Використання патерна Bridge

Шаблон «Міст» передбачає, що основний код, необхідний для функціонування

об'єкта, переноситься у реалізацію. Решта, включаючи взаємодію з клієнтом,
міститься в абстракції. Її методи, у разі потреби, можуть бути змінені або
доповнені. Крім того, вона містить екземпляр реалізації і використовує його
для обробки запитів, що надходять від клієнтів. Під обробкою мається на увазі
як пряма переадресація запиту, так і виклик групи методів реалізації для
отримання результату.
Призначення патерна Bridge

Використовуйте патерн Bridge, коли:

 хочете уникнути постійної прив’язки абстракції до реалізації
(так буває, коли реалізацію потрібно вибирати під час
виконання програми);
 і абстракція, і реалізація повинні розширюватися новими
підкласами. В такому випадку патерн Bridge дозволяє
комбінувати різні абстракції та реалізації та змінювати їх
незалежно;
 зміни в реалізації абстракції не повинні впливати на клієнтів,
тобто клієнтський код не повинен перекомпільовуватися.
Кроки реалізації

1. Визначте, чи існує у ваших класах два вимірювання, що не перетинаються. Це може бути

функціональність/платформа, предметна область/інфраструктура, фронт-енд/бек-енд або
інтерфейс/реалізація.
2. Продумайте, які операції будуть потрібні клієнтам і опишіть їх у базовому класі
абстракції.
3. Визначте поведінку, доступну на всіх платформах, і виділіть ту частину, яка потрібна
абстракції. На підставі цього напишіть загальний інтерфейс реалізації.
4. Для кожної платформи створіть свій клас конкретної реалізації. Всі вони повинні
слідувати загальному інтерфейсу, який ми виділили перед цим.
Кроки реалізації

5. Додайте до класу абстракції посилання на об'єкт реалізації. Реалізуйте методи абстракції,

делегуючи основну роботу пов'язаному об'єкту реалізації.
6. Якщо у вас є кілька варіацій абстракції, створіть для кожної свій підклас.
7. Клієнт повинен подати об'єкт реалізації в конструктор абстракції, щоб зв'язати їх докупи.
Після цього він може вільно використати об'єкт абстракції, забувши про реалізацію.
Переваги та недоліки

• Дозволяє будувати платформо-незалежні програми.

• Приховує зайві чи небезпечні деталі реалізації від клієнтського коду.
• Реалізує принцип відкритості/закритості.

• Ускладнює код програми через запровадження додаткових класів.

Коротка довідка

Якщо для деякої абстракції можливо кілька реалізацій, то зазвичай застосовують

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

ПРИКЛАД
Розглянемо реальне застосування даного патерну:
Існує безліч програмістів. Одні – фрілансери, інші працюють в компанії інженерами, а
хтось поєднує роботу в компанії та фріланс. Отже, вимальовується ієрархія різних класів
програмістів. Але ці програмісти можуть працювати з різними мовами та технологіями. І
залежно від вибраної мови діяльність програміста відрізнятиметься.
Можливе рішення проблеми

Звичайно, цю задачу можна було б вирішити за допомогою спадкування.

Ми могли б визначити абстрактний клас Programmer та його підкласи CPPProgrammer, CSharpProgrammer
та інші, які б реалізували інтерфейс програміста для різних мов та технологій. Але з різновидами
програмістів все значно ускладнюється. Нам треба додати підклас FreelanceProgrammer, який спеціалізує
абстракцію програміста-фрілансера. Щоб підтримувати програміста-фрілансера на обох мовах
програмування нам доведеться реалізувати 2 нових підкласи CPPFreelanceProgrammer та
CSharpFreelanceProgrammer. Більш того, по 2 підкласи
потрібно визначати для кожного різновида програміста.
А для підтримки 3-ї мови програмування доведеться
визначати для всіх видів програмістів новий
підклас Programmer.
Недоліки

Тобто таке рішення має такі недоліки:

 При додаванні нових різновидів програмістів та мов/технологій програмування
кількість підкласів буде рости в геометричній прогресії
 Не зручно поширювати абстракцію Programmer на інші мови програмування та
технології
Рішення проблеми
За допомогою патерну «Міст» ці проблеми вирішуються.
Класи абстракції та класи реалізації поміщаються в окремі паралельні ієрархії класів. Таким
чином, існує одна ієрархія для різновиду програмістів (Programmer, FreelanceProgrammer,
CorporateProgrammer) та інша (з коренем ILanguage) – для мов та технологій програмування.
Всі операції підкласів Programmer реалізовані в термінах абстрактних операцій з інтерфейсу
ILanguage. Це відокремлює абстракцію програміста
від різних мов програмування. Відношення між
класами Programmer і ILanguage ми називатимемо
мостом, оскільки між абстракцією та реалізацією
будується міст, і вони можуть змінюватися
незалежно.
Графічне відображення рішень
Спадкування З патерном «Міст»
Приклад програми на С# з патерном «Міст»
Для вирішення опису даної задачі в програмі на C# використовуємо патерн Міст:
Приклад програми на С# з патерном «Міст»
Дякую за
увагу!