В чем преимущество шаблона моста [закрыт]
Когда я хочу научиться чему-то новому, я спрашиваю себя, что я потерял, когда не научился этому. Я собираюсь изучить некоторые шаблоны дизайна, и все будет хорошо. Но когда я прибыл в Шаблон проектирования моста Я попал в беду. Действительно, я не могу себе представить, когда использовать этот шаблон дизайна. И я знаю, что в Google и stackoverflow есть другие ссылки, такие как это.
Но может ли кто-нибудь сказать, что мы потеряли, если забудем Bridge Design Pattern и пропустим этот шаблон?
2 answers
Схема моста заключается в том, чтобы просто заметить пару сходящихся обязанностей и разделить их. Я буду использовать пример Банды четырех (TGF), потому что я думаю, что это действительно хороший пример:
У вас есть оконный интерфейс с двумя подклассами: XWindow (на основе менеджера окон X) и PMWindow (на основе оконного менеджера IBM Presentation Manager (PM)... о котором я никогда не слышал).
Т.е.:
interface Window {}
class XWindow : Window {}
class PMWindow : Window {}
Проблема с продолжением нашего традиционного подхода к наследованию заключается в следующем что если вы специализируете окно на аспекте, отличном от его зависимости от платформы (т. Е. У вас есть некоторая ответственность, ортогональная той, для поддержки которой вы создали дерево наследования), вам необходимо использовать шаблон моста, иначе ваша иерархия классов будет расти в геометрической прогрессии. Я думаю, что хороший способ думать о мосте как о сочетании наследования и композиции.
Это довольно многословно. Возвращаясь к примеру TGF: что делать, если вам нужно окно значка и временное окно (что-то вроде стеклянной панели). Концепция "Значок против переходного" и "PM против X" - это две ортогональные идеи, но они оба пытаются попасть в одно и то же дерево наследования. Если вы не используете шаблон моста, вам нужно будет создать два новых интерфейса, унаследованных от первого, и множество классов под ними:
interface Window {}
class XWindow : Window {}
class PMWindow : Window {}
interface IconWindow : Window {}
class XIconWindow : XWindow, IconWindow {}
class PMIconWindow : PMWindow, IconWindow {}
interface TransientWindow : Window {}
class XTransientWIndow : XWindow, TransientWindow {}
class PMTransientWindow : PMWindow, TransientWindow {}
С помощью шаблона моста вы разделили бы эти две обязанности на два дерева наследования:
interface Window {}
class IconWindow : Window {} //this class...
class TransientWindow : Window {} //and this one will keep a private reference to aWindowImp
interface WindowImp: Window {}
class XWindowImp : WindowImp {}
class PMWindowImp : WindowImp {}
Намного чище, намного лучше ответственность сегрегация, и гораздо проще писать и потреблять!
Я верю, что эта проблема проектирования и странности даже дерева объектов моста на самом деле были некоторыми из проблем, лежащих в основе проектирования миксов в Scala. Используя множественное наследование C++, вы бы статически связали любые реализации с их оконной системой. Другими словами, у вас будет такое же количество типов, что и у шаблона без моста, но они, вероятно, будут пустыми классами, и вы, конечно, можете ссылаться на них с помощью абстракция, которая делает его довольно простым в использовании.
Преимущества моста заключаются в том, что абстракция и реализация отделены друг от друга. Реализация также динамически изменяется во время выполнения, и расширяемость абстракции и реализации улучшается.
Указав параметр при генерации абстракции, реализация может быть выбрана также для того, чтобы реализация клиента была полностью скрыта. Сильного увеличения количества занятий можно избежать.
