bridge pattern vs. decorator pattern

Can anybody elaborate the Bridge design pattern and the Decorator pattern for me. I found it similar in some way. I don't know how to distinguish it?

My understanding is that in Bridge, it separate the implementation from the interface, generally you can only apply one implementation. Decorator is kind of wrapper, you can wrap as many as you can.

For example,

Bridge pattern

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

}

Decorator pattern

class Shirt {
p开发者_运维知识库rivate:
Person * m_p;           //put a shirt on the person;

}

---

The Decorator should match the interface of the object you're decorating. i.e. it has the same methods, and permits interception of the arguments on the way in, and of the result on the way out. You can use this to provide additional behaviour to the decorated object whilst maintaining the same interface/contract. Note that the interface of the Decorator can provide additional functionality to create a more useful object.

The Bridge has no such constraint. The client-facing interface can be different from the underlying component providing the implementation, and thus it bridges between the client's interface, and the actual implementation (which may not be client-friendly, subject to change etc.)

---

Your decorator pattern implementation isn't quite right - It would make more sense if you did:

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

}

The idea is that, when you decorate a class, you expose the exact same interface. This makes your "decorated" instance look and act like the original. This allows you to wrap an instance many times with multiple decorators, but treat it exactly the same as you treat the original instance.

---

Decorator:

1. Add behaviour to object at run time. Inheritance is the key to achieve this functionality, which is both advantage and disadvantage of this pattern.
2. It enhances the behaviour of interface.
3. Decorator can be viewed as a degenerate Composite with only one component. However, a Decorator adds additional responsibilities - it isn't intended for object aggregation.
4. Decorator supports recursive composition
5. The Decorator class declares a composition relationship to the LCD (Lowest Class Denominator) interface, and this data member is initialized in its constructor.
6. Decorator is designed to let you add responsibilities to objects without sub-classing

Refer to sourcemaking article for more details.

UML diagram of Decorator from wikipedia:

Bridge pattern:

1. Bridge is structural pattern
2. Abstraction and implementation are not bound at compile time
3. Abstraction and implementation - both can vary without impact in client

Use the Bridge pattern when:

1. you want run-time binding of the implementation,
2. you have a proliferation of classes resulting from a coupled interface and numerous implementations,
3. you want to share an implementation among multiple objects, you need to map orthogonal class hierarchies.

UML diagram of Bridge from wikipedia:

From UML diagram, you can observe the difference:

In Decorator pattern, Decorator is implementing Component, which will be replaced by ConcreteComponent at run time.

In Bridge pattern, RedefinedAbstraction is not implementing Implementor. Instead, it uses composition so that Implementor can vary dynamically at run time without client knowledge.

Decorator can't decouple abstraction from implementation unlike Bridge pattern.

Few more useful posts:

When to Use the Decorator Pattern?

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

---

Brian is correct. I'll add that conceptually, the client will "know" it's using a bridge to an underlying object, but with a decorator, the client will be unable to know there's a decorator layer between it and the target object.

The purpose of the bridge is to create a layer of abstraction to protect the client. The purpose of the decorator is to add functionality to the object without the client knowing. Most decorators will pass along all function calls directly to a pointer to their parent class, except for functions relating directly to what the decorator is designed to change.