Структурен дизайн на мост
Присвояване на шаблон на мост
В системата може да има класове, връзките между които са изградени в съответствие със следната обектно-ориентирана йерархия: абстрактен базов клас декларира интерфейс, а конкретни подкласове го реализират според нуждите. Този подход е стандартен в OOP, но има следните недостатъци:
Система, изградена на базата на наследяване, е статична. Изпълнението е твърдо свързано с интерфейса. Вече не е възможно да се промени изпълнението на обект от някакъв тип по време на изпълнение на програмата.
Системата става трудна за поддръжка, ако броят на свързаните производни класове стане голям.
Нека обясним трудностите при разширяването на системата с нови типове, използвайки примера за разработване на логер. Логерът е система за регистриране на съобщения, която ви позволява да улавяте грешки, отстраняване на грешки и друга информация по време на изпълнение на програмата. Логерът, който разработваме, може да се използва в един от трите режима: извеждане на съобщения на екрана, във файл или изпращане на отдалечен компютър. Освен това трябва да е възможно да се използва в едно- и многонишкови среди.
Стандартният базиран на полиморфизъм подход използва следната йерархия на класовете.
Вижда се, че броят на свързаните подкласове в системата е 6. Добавянето на още един тип регистратор ще го увеличи до 8, два - до 10 и т.н. Системата става трудна за управление.
Тези недостатъци липсват в система, проектирана с помощта на модела Bridge.
Описание на модела на моста
Моделът Bridge разделя абстракцията и имплементацията в две отделни йерархии на класове, така че да могат да бъдат модифицирани независимо една от друга.
Първата йерархия дефинира интерфейса за абстракция, достъпен за потребителя. За случая на регистратора, който проектираме, абстрактният базов клас Logger може да декларира интерфейса на метода log() за показване на съобщения. Класът Logger също съдържа указател за внедряване на pimpl, който се инициализира правилно, когато се създаде определен тип logger. Този указател се използва за пренасочване на потребителски заявки към изпълнението. Обърнете внимание, че като цяло подкласовете ConsoleLogger, FileLogger и SocketLogger могат да разширят интерфейса на класа Logger.
Всички подробности за изпълнението, свързани с особеностите на средата, са скрити във втората йерархия. Базовият клас LoggerImpl декларира интерфейс за операции за изпращане на съобщения до екрана, файла и отдалечения компютър, докато подкласовете ST_LoggerImpl и MT_LoggerImpl го реализират съответно за еднонишкови и многонишкови среди. Като цяло интерфейсът LoggerImpl не трябва да съвпада точно с интерфейса на абстракцията. Често изглежда като набор от примитиви на ниско ниво.
Моделът Bridge улеснява промяната на изпълнението по време на изпълнение. За да направите това, достатъчно е да преконфигурирате указателя на pimpl към обекта за изпълнение от желания тип. Използването на модела Bridge също намалява общия брой подкласове в системата, което я прави по-лесна за поддръжка.
Мостова шарена структура
диаграма на UML класове на модела Bridge
Моделите Bridge и Adapter имат подобна структура, но целите на тяхното използване са различни. Ако моделътАдаптерсе използва за адаптиране на съществуващи класове към системата, тогава моделът Bridge се използва на етапа на проектиране.
Внедряване на модел на мост
Ето реализацията на логераизползвайки модела Bridge.