Bridge vs. Adapter Design Pattern

Question

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

Answer 1

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

Answer 2

This has been previously discussed here - Difference between Bridge pattern and Adapter pattern - The real quote you want from GoF is "Adapter makes things work after they're designed; Bridge makes them work before they are. [GoF, p219]

Your last question gets a yes - an adapter is used to make two otherwise disagreeable elements of a system play nicely together without changing their fundamental functionality beyond possibly subsetting the union of their functionalities -

A bridge pattern is usually used to deal with issues in initial design where the mental model presented to the consumer might be wildly different from the model that realizes the implementation of the consumers model. Consider a high performance math library that looks the same across a wide variety of processors - you just want to multiply matrices, but behind the scenes there's all sorts of cruft involving swizzling, parallel data streams, odd behaviors to avoid pipeline stalls, and all done differently on 3+ realizations of a high performance superscaler core - and that's just Intel :-(

Answer 3

I was explained the bridge pattern as an intend to combine two class hierarchies with different purposes. For example consider you are writing a window framework with different types of controls and support for different window systems. You'd have one class tree for the controls and another to abstract away the differences between the window systems. Now if you want to add support for another window system, you simply add that to that side of the hierarchy, and if you want to add new controls, you add them to their side. The "bridge" exists between the top classes of the two hierarchies, where your control class has access to the abstract functions defined by the base class of the class hierarchy implementing support for the various window systems.

With the adapter pattern you don't want to combine two hierarchies of classes with different intentions, but adapt a class to work with your own interface. I suppose if you only supported a single window system in the example above and don't put an abstract class inbetween to maintain extensibility, that would be an adapter instead of a bridge.