• the Hillside Group Pattern's home page

• TechBookReport - Reviews of books on design patterns including recommended titles.

• Holub on Patterns by Allen Holub. Very code-centric book on patterns as they appear in real Java code rather than in the simplified examples of pattern catalogues.

• TechBookReport - Reviews of books on design patterns including recommended titles.

• Head First Design Patterns by Eric and Elisabeth Freeman. A very different and user-friendly introduction to the classic GoF^? patterns in Java.
• Design Patterns Explained by Alan Shalloway and James R. Trott. Good introductory book, with Java examples.

• MessageExchangePatterns

Rick, I agree that patterns are definitely overused. However, I don't think the current situation is as dire as you predict. Although lots of people has recently written pattern books, only the most used ones will continue to be referenced by the community. The rest will fade into obscurity because they really didn't describe design patterns (which must be common). It's natural selection!

While I also agree that some patterns are more useful in some languages than others, I disagree with your statement that Java's interface mechanism makes many of the GOF patterns obsolete. In fact, I think the buit-in support makes them easier to implement in Java. Wasn't that the point of interfaces? -- Quantum Jim, 10 Dec 2004.

I've found the best way to use design patterns is after coding has started. Often a program will accidently end up designed with part of a pattern. So after a little bit of coding, I tend to look for patterns and reevaulate my design choices. Good patterns are common solutions to common problems with the advantages and disadvantages already traced out. So I'll either refactor toward that pattern or away from it depending on whether the pattern's concequences, strengths, and trad-offs are appropiate for the program. -- Quantum_Jim, 26 Nov 2004.

I'm starting to think that one of the main benifits of Design Patterns are as case studies or examples of how to apply the main principles of good OOD to common problems in a general way. -- Quantum_Jim, 10 Dec 2004.

Where would you recommend someone who is new to patterns to get started? Is the Gang of Four's book a must-read? -- Afishionado.

The GOF Book is definitely a must read, even if you never touch C++ or Smalltalk. The code is simple enought that a 1-day refresher on the languages is enough. However, the principles are timeless, and their introduction is the best that I've read.

Where would you recommend someone who is new to patterns to get started? Is the Gang of Four's book a must-read?

• A Pattern Enforcing Compiler (PEC) for Java

To illustrate these points, I'll make an analogy to writing. "It was a dark and stormy night" Might be a perfectly good first line for some books. However, you wouldn't use it for every book, nor would you start every chapter with it, and starting every new paragraph with it would be right out.

For patterns, its not too hard to find people who make practically every object a Singleton, Factory or Proxy... or... horror of horrors, a Singleton Factory Proxy...

Patterns, like UML could be a really intended to improve the communication between programmers. To give us a common vocabulary to describe typical problems and solutions. Unfortunately, EverybodyAndTheirDog^? put out a pattern book with whatever clever little bits of code they had lying around which they were particularly proud of (contrast with the original programming patterns book where each pattern had to have occurred in several (at least three?) different places to be considered). As an end result there are too many patterns, and even the 'main ones', people have different ideas about what they mean.

One pattern advocate recently tried to engage me in a discussion about whether Singleton was an access or a creational pattern. My take was that no matter what the original intention was, it has been subverted now (by the masses) into 'a final static variable and a private constructor which instantiates the static if it dodn't already exist'. Common usage trumps all.

Patterns for one programming language may be barely worth mentioning for another. Eg a language with closures is going to view things like Visitor and Iterator differently than one without that feature. A lot of the original programming patterns have to do with abstracting the interface away from the implementation. And Java has a 100% abstract interface mechanism built right into the language.

I've found the best way to use design patterns is after coding has started. Often a program will accidently end up designed with part of a pattern. So after a little bit of coding, I tend to look for patterns and reevaulate my design choices. Good patterns are common solutions to common problems with the advantages and disadvantages already traced out. So I'll either refactor toward that pattern or away from it depending on whether the pattern's concequences, strengths, and trad-offs are appropiate for the program.

A big danger facing people designing with patterns is the urge to use patterns for the sake of using patterns and not because they serve a purpose. As a result applications get overly complex and performance suffers as far too many objects are created. Codebloat and dissatisfied users are the result, as well as hard to maintain code. Example: A model-view-controller architecture where every layer is designed as a model-view-controller architecture. All communication between (sub)layers requires custom objects created using abstract factories (which themselves are accessible only through special factories).

I've seen this in real life, this is not a contrived example.

Performance was extremely poor, the codebase was over 100MB for a relatively small application that could have been written in maybe 5% of the code.

Be very careful when designing using Patterns. There is an oft overlooked aspect that each Pattern has Consequences.

Hence if when you sit down to do the design you slap down a whole bunch of Patterns, you can inadvertently set yourself up for a lot of unneccessary problems.

Two examples:

• Pooling resources that it turns out did not need to be pooled might limit the throughput of the system, with user requests being blocked while they wait for pooled resources to become available, even though the machine might have plenty of spare CPU and memory at that time.

• A Singleton that in later versions of the program you would have preferred to be able to subclass, or where you find you actually need more than one (in some respects a Singleton might end up acting like a Pool of one), or where different parts of the system end up in different JVMs (eg a distributed system: which most discussions of Singletons fail to take into account).

The good news, is that if you and the other developers all share a common terminology, it can vastly improve communication between the developers, and make it easier for anyone else who shares that terminology to pick up the code and run with it in a maintenance type role.

• Design pattern on Wikipedia

• DataAccessObject

• Data List Handler: A Pattern for Large Search Result Sets
• Making your J2EE Application Web Services ready - The XML Business Delegate Pattern

• J2EE Patterns
• Design Patterns in Java: Reference and Example Site
• Design Patterns for Building Flexible and Maintainable J2EE Applications

Books on patterns:

• Patterns in Java, Volume 1 by Mark Grand.
• Core J2EE Patterns: Best Practices and Design Strategies
• Bug Patterns In Java by Eric Allen.

• Enterprise Application Integration Patterns

• Portland Pattern Repository's Wiki

Software patterns came about when a number of computer scientists applied Alexander's work to programming. The first major book of software patterns was Design Patterns by ErichGamma^?, RichardHelm^?, RalphJohnson^?, and JohnVlissides published in 1995. A pattern from their book is Singleton.

While patterns represent best practices, AntiPatterns describe common mistakes.

Here are some other pages in the Javapedia about patterns:

• EnterpriseApplicationIntegrationPatterns

Other websites that discuss patterns include:

• the Hillside Group [[http://www.hillside.net/patterns/patterns.htm] [Pattern's home page]]
• Christopher Alexander's website

• Singleton

Patterns

Pattern - a plan or model used as a guide for making things

Discussion about Patterns