шаблон моста против шаблона декоратора

Question

Может ли кто-нибудь разработать для меня шаблон дизайна моста и шаблон декоратора. Я нашел это похожим в некотором роде. Я не знаю, как это отличить?

Насколько я понимаю, в Bridge отделена реализация от интерфейса, обычно вы можете применять только одну реализацию. Декоратор - это своего рода обертка, вы можете завернуть столько, сколько сможете.

Например,

Образец моста

class Cellphone {
private:
Impl* m_OS;         // a cellphone can have different OS

}

Шаблон декоратора

class Shirt {
private:
Person * m_p;           //put a shirt on the person;

}

Answer 1

Декоратор должен соответствовать интерфейсу объекта, который вы украшаете. то есть он имеет те же методы и позволяет перехватывать аргументы при входе и результаты при выходе. Вы можете использовать это для предоставления дополнительного поведения декорированному объекту при сохранении того же интерфейса / контракта. Обратите внимание, что интерфейс Декоратора может предоставить дополнительные функциональные возможности для создания более полезного объекта.

Мост не имеет такого ограничения. Клиентский интерфейс может отличаться от базового компонента, обеспечивающего реализацию, и, таким образом, он связывает между клиентским интерфейсом и фактической реализацией (которая может быть не дружественной к клиенту, может изменяться и т. Д.)

Answer 2

Ваша реализация шаблона декоратора не совсем верна - было бы больше смысла, если бы вы сделали:

class PersonWearingShirt : IPerson
{
private:
    IPerson * m_p;           //put a shirt on the person;

}

Идея в том, что когда вы украшаете класс, вы выставляете точно такой же интерфейс. Это делает ваш «украшенный» экземпляр похожим на оригинал. Это позволяет вам многократно оборачивать экземпляр несколькими декораторами, но обрабатывать его точно так же, как и исходный экземпляр.

Answer 3

декоратор:

1. Добавить поведение к объекту во время выполнения . Наследование является ключом для достижения этой функциональности, что является как преимуществом, так и недостатком этого шаблона.
2. Улучшает поведение интерфейса.
3. Декоратор можно рассматривать как вырожденный композит с одним компонентом. Однако декоратор добавляет дополнительные обязанности - он не предназначен для агрегирования объектов.
4. Декоратор поддерживает рекурсивную композицию
5. Класс Decorator объявляет композиционные отношения с интерфейсом LCD (самый низкий знаменатель класса), и этот элемент данных инициализируется в своем конструкторе.
6. Декоратор позволяет добавлять обязанности к объектам без подклассов

Подробнее см. В статье sourcemaking .

UML-схема декоратора из википедии :

Схема моста:

1. Мост структурный рисунок
2. Абстракция и реализация не связаны во время компиляции
3. Абстракция и реализация - оба могут изменяться без влияния на клиента

Использовать шаблон Мост, когда:

1. Вы хотите привязку реализации во время выполнения,
2. у вас есть множество классов, возникающих в результате связанного интерфейса и многочисленных реализаций,
3. вы хотите поделиться реализацией между несколькими объектами, вам нужно отобразить ортогональные иерархии классов.

UML-схема моста из википедии :

Из диаграммы UML вы можете наблюдать разницу:

В шаблоне Decorator Decorator реализует Компонент, который будет заменен ConcreteComponent во время выполнения .

В паттерне Bridge RedefinedAbstraction не реализует инструмент реализации. Вместо этого он использует композицию, так что Implementor может динамически изменяться во время выполнения без ведома клиента.

Декоратор не может отделить абстракцию от реализации в отличие от шаблона Bridge.

Еще несколько полезных постов:

Когда использовать шаблон декоратора?

Когда вы используете шаблон моста? Чем он отличается от шаблона адаптера?

Answer 4

Брайан прав. Я добавлю это концептуально, клиент будет «знать», что он использует мост к базовому объекту, но с декоратором клиент не сможет знать, что между ним и целевым объектом есть слой декоратора.

Цель моста - создать уровень абстракции для защиты клиента. Цель декоратора - добавить функциональность к объекту без ведома клиента. Большинство декораторов передают все вызовы функций непосредственно указателю на их родительский класс, за исключением функций, связанных напрямую с тем, что декоратор предназначен для изменения.