Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Design patterns, the big picture, Part 1: Design pattern history and classification

Understanding the concept and use of design patterns in software development

By Jeff Friesen, JavaWorld.com, 11/21/12

  • Print
  • Feedback
.

Page 3 of 6

More about Double-checked locking

See "Double-checked locking: Clever, but broken" and "Can double-checked locking be fixed?" (Brian Goetz, JavaWorld) to learn more about why this pattern didn't work in JDK 1.4 and earlier. For more about specifying DCL in JDK 5 and later, see "The 'Double-Checked Locking is Broken' Declaration" (University of Maryland Department of Computer Science, David Bacon, et al.).

 

Anti-patterns

When a design pattern is commonly used but is ineffective and/or counterproductive, the design pattern is known as an anti-pattern. One might argue that Double-checked locking as used in JDK 1.4 and earlier was an anti-pattern. I would say that it was merely a bad idea in that context. For a bad idea to evolve into an anti-pattern, the following conditions must be met (see Resources).

  • A repeated pattern of action, process, or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results.
  • An alternative solution exists that is clearly documented, proven in practice, and repeatable.

While Double-checked locking in JDK 1.4 did meet the first requirement of an anti-pattern, it did not meet the second: although you could use synchronized to solve the problem of lazy initialization in a multithreaded environment, doing so would have defeated the reason for using Double-checked locking in the first place.

Deadlock anti-patterns

Recognizing anti-patterns is a prerequisite to avoiding them. Read Obi Ezechukwu's three-part series for an introduction to three anti-patterns famous for causing deadlock:

Design pattern history

Design patterns date back to the late 1970s with the publication of A Pattern Language: Towns, Buildings, Construction by architect Christopher Alexander and a few others. This book introduced design patterns in an architectural context, presenting 253 patterns that collectively formed what the authors called a pattern language.

The irony of design patterns

Although design patterns used for software design trace their beginning to A Pattern Language, this architectural work was influenced by the then-emerging language to describe computer programming and design.

The concept of a pattern language subsequently emerged in Donald Norman's and Stephen Draper's User Centered System Design, which was published in 1986. This book suggested the application of pattern languages to interaction design, which is the practice of designing interactive digital products, environments, systems, and services for human use.

Meanwhile, Kent Beck and Ward Cunningham had begun to study patterns and their applicability to software design. In 1987, they used a series of design pattern to assist Tektronix's Semiconductor Test Systems Group, which was having trouble finishing a design project. Beck and Cunningham followed Alexander's advice for user-centered design (letting representatives of the project's users determine the design outcome) while also providing them with some design patterns to make the job easier.

  • Print
  • Feedback

Resources

David Geary's Java design patterns series is an excellent first stop for learning about some of the Gang of Four patterns mentioned in this article:

Allen Holub wrote about several important concurrency patterns and other design techniques for his Java toolbox series, "Programming Java in the real world":

Brian Goetz's two JavaWorld articles about double-checked locking are essential reading for anyone inclined to put too much faith in an out-of-the-box solution:

Design patterns are discussed in JavaWorld's Java 101, Java tips and Java Q&A series:

Some patterns have become more important with time:

Others have stood the test of time:

Additional resources for learning about design patterns: