Pattern: a plan or model used as a guide for making things
Patterns and Pattern Languages? can be thought of as ways to describe best practices, good designs, and capture experience in a way that it is possible for others to reuse this experience. The use of patterns to help architects and builders was pioneered by the architect Christopher Alexander? and his colleagues at the University of California, Berkeley, in the 1960s and 1970s. Alexander focused on patterns for creating vibrant homes and buildings—expousing a property he called the Quality Without A Name?. See his books The Timeless Way Of Building and also A Pattern Language.
Design patterns, which constitute a type of software pattern, came about when a number of computer scientists applied Alexander's concepts to programming. The first major book of software patterns was Design Patterns by Erich Gamma?, Richard Helm?, Ralph Johnson?, and John Vlissides published in 1995. Some patterns from their Gang of Four book are Singleton and Proxy.
While patterns represent best practices, AntiPatterns describe common mistakes. Implementaton level AntiPatterns are sometimes called Bug Patterns.
Here are some other pages in the Javapedia about patterns:
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.
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.
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.
-- rickcarson.
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.
-- jwenting, 21 Apr 2004.
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.
-- rickcarso, 29 Nov 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 trade-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.Another useful book is Patterns in Java Vol. 1 by Mark Grand. His book features some additional patterns, UML, and Java code examples. However, the format of the book makes quickly referencing the patterns extremely hard. One of GOF's strengths is that it includes handy cross references in the covers as well as lists and diagrams showing the relationships between patterns. PIJ follows the conventions of a standard textbook on Philosophy for instance - entirely inappropiate. However, PIJ is still useful and contains a better explaniation of the Visiter Pattern (IMHO). However, the book is not a substitute for GOF's masterpiece.I can NOT recommend The Design Patterns Java Companion by James Cooper. Coop seems to just reexplain the GOF patterns with poor explaniations and aweful diagrams. That online book was renamed "Java Design Patterns: A Tutorial" with further explaniations. Don't bother with either.There are three very useful resources on the web about patterns that I can recommend. The Portland Pattern Repository Pattern Index is perhaps the most encompassing; however, it is often hard to find stuff among the millions of links. (I often edit pages there as JimmyCerra.) Another good resource is Wikipedia's entry on Patterns. Not as informative as the WikiWikiWeb's index, but much easier to read. Finally, check out Uncle Bob's articles on patterns at Objectmentor. Martin's articles are very insightful and his "principle" series from C++ Report is top-notch.-- Quantum_Jim, 10 Dec 2004.