In software design, a design pattern is a proven and reusable solution to a commonly occurring problem in a determined context.

The idea behind design patterns comes from Christopher Alexander’s book, A Pattern Language (1977), which talks about architectural patterns in buildings and towns. Ten years later, Kent Beck and Ward Cunningham started to apply the patterns to software development. It became popular when the Gang of Four’s book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994.

Wouldn’t it be great if we were able to apply the appropriate patterns in sequence to obtain the complete design for a software system? Well, we are not there yet… (Are we? See how JUnit was designed in JUnit A Cook’s Tour). Design patterns provide quality, elegance, flexibility and reuse to the systems that use them, but they are intended for small scale, partial solutions, ignoring the big picture. Other concerns such as system complexity, maintainability and performance, architectural issues, have to be taken into account (for this we have architectural patterns, but this could be another blog post). Also, there is no well-defined, systematic approach to apply design patterns, and the possible problem domains in software engineering are so wide that it is difficult to say that we’ve already found all the necessary design patterns to solve them.

Despite of all these limitations, design patterns have evident advantages and it is surprising to see people heavily involved in software development not having heard of them. Currently, design patterns can be found anywhere, even for specialized areas such as Java EE, with its recommended core patterns. Interestingly enough, these patterns, along with those from the Gang of Four, are an important part of the Sun certificaction for enterprise architects, SCEA, which clearly shows their relevance.

Design patterns are perfectly aligned with ISIS principle of “not reinventing the wheel”. They are recommended to ILOG consultants and the methodology contains guidance on them.

The following picture shows the “ubiquitous” singleton pattern, such as it is presented in the ISIS guide for leveraging design patterns.

More generally, there is no good or bad design patterns, they are all useful to some contexts. They are not all relevant to every decision-support system, but most of them are, especially when you consider the other layers and services surrounding a decisioning application. Overall they represent a key concept to leverage during design phases and also to keep in mind to identify new ones which can be reused from one project to another.

What about you? What do you think of design patterns? Do you normally use design patterns in your projects? Have you come with new ones?