From GOF
The Adapter and Bridge patterns have some common attributes. Both promote flexibility by
providing a level of indirection to another object. Both involve forwarding requests to this object from an interface other than its own.
The key difference between these patterns lies in their intents. Adapter focuses on resolving
incompatibilities between two existing interfaces. It doesn't focus on how those interfaces are
implemented, nor does it consider how they might evolve independently. It's a way of making two
independently designed classes work together without re-implementing one or the other. Bridge, on the other hand, bridges an abstraction and its (potentially numerous) implementations. It provides a stable interface to clients even as it lets you vary the classes that implement it. It also accommodates new implementations as the system evolves.
As a result of these differences, Adapter and Bridge are often used at different points in the software
life-cycle. An adapter often becomes necessary when you discover that two incompatible classes should work together, generally to avoid replicating code. The coupling is unforeseen. In contrast, the user of a bridge understands up-front that an abstraction must have several implementations, and both may evolve independently. The Adapter pattern makes things work after they're designed; Bridge makes them work before they are. That doesn't mean Adapter is somehow inferior to Bridge; each pattern merely addresses a different problem.
You might think of a facade as an adapter to a set of other objects. But that
interpretation overlooks the fact that a facade defines a new interface, whereas an adapter reuses an old interface. Remember that an adapter makes two existing interfaces work together as opposed to defining an entirely new one.
Please refer examples
Adapter
Bridge
No comments:
Post a Comment