There are tons of interminable debates and controversies around design patterns. The current post doesn’t intend to add a new one or to create waves. It just relates to a few mistakes that are done when comparing “similar” patterns.
From time to time, we organize internal design patterns presentations. Most of the time the presentation format is like this: a guy picks a pattern and presents it, during presentation we ask questions and discuss about it, at the end we compare it with other “similar” patterns and underline the advantages (testing, reusability etc.).
The presenters choose to show real code in order to convince the audience about the pattern and the similarities with other patterns. Even if it is a good practice, the real problem addressed by the pattern will be overlooked if you consider only the code.
When comparing two patterns the audience falls into the sin of analyzing them in terms of classes and responsibilities. This happens because the pattern code was written a few months ago and it’s hard to remember why you decided to use the pattern. Often the pattern intention is in the shadow of the testability and reusability arguments. In this case you might end up with implementing a particular pattern even if the problem claims for another. Therefore in such discussions the focus should be on the intention of the pattern and the problems it resolves.
For instance it is very easy to confuse the Adapter with the Bridge if you are looking only to the code and you don’t know the real intention of such an implementation decision. The purpose of the adapter is to adapt the interface of an existing component in order to simplify or to meet your requirements. The consequence of this is that you don’t access the component directly in the client. On the other hand the role of a Bridge is to vary the implementation. This makes it suitable for plugging specific implementation at runtime. Again the result is the isolation from the client. This obvious consequence makes them easy to confuse. The Adapter is a decision made most of the time during the low level design in order to simplify the integration of third party components. The Bridge pattern is considered up-front (high level design) because you will need it in order to impress a specific behavior to the system more than to simplify the implementation (component integration and isolation).
Here are two scenarios that give you a flavor of how things influence the decision:
1. Let’s suppose that a development team decide to use an existing open-source component with some functionality that will take them too much time to develop. That component has a lot of additional functionality that is not needed and the interface is too complex for using directly. The good decision is to add an adapter between the application and the third party component. This will simplify the interface and will isolate the client code from accessing directly the component. In this case the component already exists and the only concern is how to manipulate it in an easy way.
2. A customer asked to develop a client application for 2 platforms: Windows XP and WinCE. The software company has 3 teams: one that develops agnostic-platform functionality and a team for each specific platforms. During the high level design the architect decided to use the bridge pattern. Each platform team develops a component that is platform specific and which conforms to an interface contract. The common functionality will be developed making the assumption that at some point the specific platform functionality will be provided. The bridge shouldn’t be thought as a middle man because it can mix the interface operations and maybe custom functionality to provide consistent services to higher levels.
As a conclusion when comparing similar patterns first consider the purpose of the pattern before drilling into implementation details. It will be very hard to make a clear distinction using only code samples and ignoring the intention behind that.
