Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

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

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

Page 2 of 6

1. A name that describes the design pattern and gives us a vocabulary for discussing it
2. A problem that identifies the design problem needing to be solved along with the context in which the problem occurs
3. A solution to the problem, which (in a software design pattern context) should identify the classes and objects that contribute to the design along with their relationships and other factors
4. An explanation of the consequences of using the design pattern

In order to identify the appropriate design pattern to use, you must first clearly identify the problem that you're trying to solve; that's where the problem element of the design pattern description is helpful. Choosing one design pattern over another also usually involves trade-offs that can impact an application's or system's flexibility and future maintenance. That's why it's important to understand the consequences of using a given design pattern before you begin implementing it.

Evaluating a design pattern

Consider the task of designing a complex user interface using buttons, textfields, and other non-container components. The Composite design pattern regards containers as components, which lets us nest containers and their components (containers and non-containers) within other containers, and do so recursively. If we chose not to use the Composite pattern we would have to create many specialized non-container components (a single component combining a password textfield and a login button, for example), which is harder to achieve.

Having thought this through, we understand the problem we're trying to solve and the solution offered by the Composite pattern. But what are the consequences of using this pattern?

Using Composite means that your class hierarchies will mix container and non-container components. Simpler clients will treat container and non-container components uniformly. And it will be easier to introduce new kinds of components into the UI. Composite can also lead to overly generalized designs, making it harder to restrict the kinds of components that can be added to a container. Since you won't be able to rely on the compiler to enforce type constraints, you will have to use runtime type checks.

It is also possible to choose an appropriate design pattern and use it incorrectly. The Double-Checked locking pattern is a classic example. Double-checked locking reduces lock acquisition overhead by first testing a locking criterion without actually acquiring the lock, and then only acquiring the lock if the check indicates that locking is required. While it looked good on paper, Double-checked locking in JDK 1.4 had some hidden complexities. When JDK 5 extended the semantics of the volatile keyword, developers were finally able to reap the benefits of the Double-checked locking pattern.