23.07.2012 Views

Design Patterns Explained

Design Patterns Explained

Design Patterns Explained

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

While the solution I developed with the Bridge pattern is far superior<br />

to the original solution, it is not perfect. One way of measuring<br />

the quality of a design is to see how well it handles variation. Handling<br />

a new implementation is very easy with a Bridge pattern in<br />

place. The programmer simply needs to define a new concrete<br />

implementation class and implement it. Nothing else changes.<br />

However, things may not go so smoothly if I get a new concrete<br />

example of the abstraction. I may get a new kind of Shape that can<br />

be implemented with the implementations already in the design.<br />

However, I may also get a new kind of Shape that requires a new<br />

drawing function. For example, I may have to implement an<br />

ellipse. The current Drawing class does not have the proper method<br />

to do ellipses. In this case, I have to modify the implementations.<br />

However, even if this occurs, I at least have a well-defined process<br />

for making these changes (that is, modify the interface of the Drawing<br />

class or interface, and modify each Drawing derivative accordingly)—this<br />

localizes the impact of the change and lowers the risk<br />

of an unwanted side effect.<br />

Bottom line: <strong>Patterns</strong> do not always give perfect solutions. However,<br />

because patterns represent the collective experience of many<br />

designers over the years, they are often better than the solutions<br />

you or I might come up with on our own.<br />

In the real world, I do not always start out with multiple implementations.<br />

Sometimes, I know that new ones are possible, but they<br />

show up unexpectedly. One approach is to prepare for multiple<br />

implementations by always using abstractions. You get a very<br />

generic application.<br />

Chapter 9 The Bridge Pattern 153<br />

But I do not recommend this approach. It leads to an unnecessary<br />

increase in the number of classes you have. It is important to write<br />

code in such a way that when multiple implementations do occur<br />

(which they often will), it is not difficult to modify the code to<br />

The Bridge pattern<br />

solution is good, but<br />

not always perfect<br />

Follow one rule, one<br />

place to help with<br />

refactoring

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!