Patterns Happy

Prev don't be afraid of buying books Next

On the back cover of Contributing to Eclipse [Gamma and Beck], a brief biography of Erich Gamma says, "Erich Gamma shared his joy in the order and beauty of software design as coauthor of the classic Design Patterns." If you've ever produced or encountered an excellent design using patterns, you know this joy.

On the other hand, if you've ever produced or encountered patterns-dense code that is poorly designed because it doesn't require the flexibility or sophistication of patterns, you know the dread of patterns.

The overuse of patterns tends to result from being patterns happy. We are patterns happy when we become so enamored of patterns that we simply must use them in our code. A patterns-happy programmer may work hard to use patterns on a system just to get the experience of implementing them or maybe to gain a reputation for writing really good, complex code.

A programmer named Jason Tiscioni, writing on SlashDot (see, perfectly caricatured patterns-happy code with the following version of Hello World.

 interface MessageStrategy {    public void sendMessage(); } abstract class AbstractStrategyFactory {    public abstract MessageStrategy createStrategy(MessageBody mb); } class MessageBody {    Object payload;    public Object getPayload() {       return payload;    }    public void configure(Object obj) {       payload = obj;    }    public void send(MessageStrategy ms) {       ms.sendMessage();    } } class DefaultFactory extends AbstractStrategyFactory {    private DefaultFactory() {    }    static DefaultFactory instance;    public static AbstractStrategyFactory getInstance() {       if (instance == null)          instance = new DefaultFactory();       return instance;    }    public MessageStrategy createStrategy(final MessageBody mb) {       return new MessageStrategy() {          MessageBody body = mb;          public void sendMessage() {             Object obj = body.getPayload();             System.out.println(obj);          }       };    } } public class HelloWorld {    public static void main(String[] args) {       MessageBody mb = new MessageBody();       mb.configure("Hello World!");       AbstractStrategyFactory asf = DefaultFactory.getInstance();       MessageStrategy strategy = asf.createStrategy(mb);       mb.send(strategy);    } } 

Have you ever seen code that resembles Jason's Hello World program? I certainly have, on too many occasions.

The patterns-happy malady isn't limited to beginner programmers. Intermediate and advanced programmers fall prey to it too, particularly after they read sophisticated patterns books or articles. For example, I discovered an implementation of the Closure pattern on a system I was helping to develop. It turned out that a programmer on the project had just learned the Closure pattern by studying it on the Wiki Web (

As I studied this Closure implementation, I could not find a good justification for using it. The Closure pattern just wasn't necessary. So I refactored the Closure pattern out of the code and replaced it with simpler code. When I finished, I asked the programmers on the team if they thought the newer code was simpler than the Closure code. They said yes. Eventually the author of the code also acknowledged that the refactored code was simpler.

It is perhaps impossible to avoid being patterns happy on the road to learning patterns. In fact, most of us learn by making mistakes. I've been patterns happy on more than one occasion.

The true joy of patterns comes from using them wisely. Refactoring helps us do that by focusing our attention on removing duplication, simplifying code, and making code communicate its intention. When patterns evolve into a system by means of refactoring, there is less chance of over-engineering with patterns. The better you get at refactoring, the more chance you'll have to find the joy of patterns.


Refactoring to Patterns (The Addison-Wesley Signature Series)
Refactoring to Patterns
ISBN: 0321213351
EAN: 2147483647
Year: 2003
Pages: 103

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: