Bridge vs. Adapter Design Pattern

Kamyar Nazeri picture Kamyar Nazeri · May 17, 2012 · Viewed 8.1k times · Source

I was questioned by a colleague about the design pattern of my implementation of a WCF windows service in a ASP.net client application and I really could not tell whether it is Bridge or Adapter!

Here is the implementation:

  • I have obtained the service contract
  • Defined a new interface similar to my WCF Data contract
  • I created a WCF client and wrapped it inside the new interface
  • Mapped the new interface operations to the original WCF client (I do some logging/error handling here)

I was always thinking of it as an implementation of Adapter pattern, but really I can not tell why isn't it Bridge!

I have read all the posts here in SO, GoF and wikipedia but it really makes no sense!

From my understanding, Both patterns point at an existing type, both decouple an abstraction from its implementation am I missing a point?

Here's from GoF:

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 reimplementing 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.

I don't fully understand the above statement,

  1. Does it mean that if I vary the adaptee or change the implementation of the original interface at design time then it is Bridge Pattern?
  2. The differences sounds trivial, Is there any other differences in implementation/abstcation?
  3. How can anyone tell what implementation is used after development?
  4. Can anyone give me a good example of bridge pattern and how it can be changed during software lifecycle?

Update:

Again from GoF:

Remember that an adapter makes two existing interfaces work together as opposed to defining an entirely new one.

Does it mean that changing the existing interface so that it can work with another interface is an implementation of Adapter?

Update2:

Just found this incredible article: Illustrated GOF Design Patterns in C#

This is true Bridge Patter structure:

I was missing the fact that the Bridge pattern lets you combine the different abstractions and implementations and extend them independently enter image description here

Answer

Sergey Berezovskiy picture Sergey Berezovskiy · May 17, 2012

I think you don't have pure GoF pattern here. It's something between Decorator and Adapter. You are changing interface of service client (adapting it to your needs). But also you are adding new responsibilities to client (logging and error handling) - thats a decorating part. If you would stay with original service interface, it would be pure Decorator.

UPDATE: Any usage of inheritance does not mean, that we are using some GoF pattern. There are several things your current architecture missing to be Bridge:

  • Hierarchy of implementations. Your service interface should define some low-level operations. And you should have several service implementations.
  • Abstraction should define high-level interface. Usually those interfaces does not look similar to implementation interface (your client interface is similar to service interface, it exists on same level of abstraction).
  • Abstraction implementations should use service interface to implement high-level operations (i.e. they don't add some responsibilities to service, they implement different things, high-level things).