桥接模式与装饰器模式

Question

有人能为我详细介绍一下Bridge设计模式和Decorator模式吗？我发现它在某种程度上很相似。我不知道该如何区分它？

我的理解是，在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

装饰器应该与你正在装饰的对象的接口相匹配。也就是说，它具有相同的方法，并允许在进入的过程中拦截参数，以及在退出的过程中拦截结果。您可以使用它来为装饰的对象提供额外的行为，同时保持相同的接口/契约。请注意，Decorator的接口可以提供额外的功能来创建更有用的对象。

桥没有这样的约束。面向客户端的接口可以不同于提供实现的底层组件，因此它在客户端的接口和实际实现(可能不是客户端友好的，可能会发生变化等)之间架起桥梁。

Answer 2

你的装饰器模式实现不太正确-如果你这样做了，它会更有意义：

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

}

其思想是，当您修饰一个类时，您公开了完全相同的接口。这会让你的“装饰”实例看起来和原来的一样。这允许您使用多个装饰器多次包装一个实例，但对待它的方式与对待原始实例的方式完全相同。

Answer 3

装饰者：

在运行时时对象的

1. Add行为。继承是实现此功能的关键，这是此模式的优点和缺点。它增强了interface.
2. Decorator的行为可以看作是一个只有一个组件的退化的
3. 。然而，装饰器增加了额外的职责-它不是为了对象aggregation.
4. Decorator支持递归composition
5. The装饰器类声明了一个组合关系到LCD (最低类分母)接口，这个数据成员是在它的constructor.
6. Decorator中初始化的，旨在让你在没有sub-classing

的情况下向对象添加职责

有关更多详细信息，请参阅sourcemaking文章。

来自wikipedia的装饰器的UML图

​

​

桥接模式：

client

• 桥是结构化的，实现不受编译time

• Abstraction和实现的限制--两者在

中都可以不同，不受影响

在以下情况下使用桥接模式：

1. 你想要运行时绑定实现，
2. 你有大量的类是由耦合的接口和大量的实现产生的，
3. 你想要在多个对象之间共享一个实现，你需要映射正交的类hierarchies.

来自wikipedia的桥的UML图

​

​

从UML图中，您可以观察到不同之处：

在装饰器模式中，装饰器实现的是组件，在运行时将被ConcreteComponent替换。

在桥模式中，RedefinedAbstraction没有实现Implementor。相反，它使用组合，以便Implementor可以在运行时动态变化，而不需要客户知道。

与桥接模式不同，装饰器不能将抽象与实现解耦。

更多有用的帖子：

When to Use the Decorator Pattern?

When do you use the Bridge Pattern? How is it different from Adapter pattern?