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 4 of 6

Erich Gamma also realized the importance of recurring design patterns while working on his PhD thesis. He believed that design patterns could facilitate the task of writing reusable object-oriented software, and pondered how to document and communicate them effectively. Prior to the 1991 European Conference on Object-Oriented Programming, Gamma and Richard Helm started to catalog patterns.

At an OOPSLA workshop held in 1991, Gamma and Helm were joined by Ralph Johnson and John Vlissides. This Gang of Four (GoF), as they subsequently were known, went on to write the popular Design Patterns: Elements of Reusable Object-Oriented Software, which documents 23 design patterns in three categories.

The modern evolution of design patterns

Design patterns have continued to evolve since the original GoF book, especially as software developers have confronted new challenges related to changing hardware and application requirements.

In 1994, a U.S.-based non-profit organization known as the Hillside Group inaugurated Pattern Languages of Programs, a group of annual conferences whose aim is to develop and refine the art of software design patterns. These ongoing conferences have yielded many examples of domain-specific design patterns. For example, design patterns in a concurrency context.

In 1998 Mark Grand released Patterns in Java. This book included design patterns not found in the GoF book, including concurrency patterns. Grand also used the Unified Modeling Language (UML) to describe design patterns and their solutions. The book's examples were expressed and described in the Java language.

Software design patterns by classification

Modern software design patterns are broadly classified into four categories based on their use: creational, structural, behavioral, and concurrency. I'll discuss each category and then list and describe some of the prominent patterns for each one.

Creational patterns

A creational pattern abstracts the process of instantiation, separating how objects are created, composed, and represented from the code that relies on them. Class creational patterns use inheritance to vary the classes that are instantiated, and object creational patterns delegate instantiation to other objects.

• Abstract factory: This pattern provides an interface to encapsulate a group of individual factories that have a common theme without specifying their concrete classes.
• Builder: Separates the construction of a complex object from its representation, enabling the same construction process to create various representations. Abstracting the steps of object construction allows different implementations of the steps to construct different representations of the objects.
• Factory method: Defines an interface for creating an object, but lets subclasses decide which class to instantiate. This pattern lets a class defer instantiation to subclasses. Dependency injection is a related pattern. (See Resources.)
• Lazy initialization: This pattern gives us a way to delay object creation, database lookup, or another expensive process until the first time the result is needed.
• Multiton: Expands on the singleton concept to manage a map of named class instances as key-value pairs, and provides a global point of access to them.
• Object pool: Keep a set of initialized objects ready to use, rather than be allocated and destroyed on demand. The intent is to avoid expensive resource acquisition and reclamation by recycling objects that are no longer in use.
• Prototype: Specifies the kinds of objects to create using a prototypical instance, then create new objects by copying this prototype. The prototypical instance is cloned to generate new objects.
• Resource acquisition is initialization: This pattern ensures that resources are automatically and properly initialized and reclaimed by tying them to the lifespan of suitable objects. Resources are acquired during object initialization, when there is no chance of them being used before they are available, and released with the destruction of the same objects, which is guaranteed to take place even in the case of errors.
• Singleton: Ensures that a class has only one instance and provides a global point of access to this instance.

Structural patterns

A structural pattern teaches us how to compose classes and objects to form larger structures. A structural class pattern relies on inheritance to compose a resulting interface or implementation (for example, multiple inheritance mixes two or more classes into one class). A structural object pattern composes various objects to obtain new functionality; the Composite pattern is one example of this approach.