Reasons for using Design Patterns

What is a Design Pattern?
Following on from my previous post about Why design is critical to software development, I would like to tackle a slightly more advanced aspect of software design called Design Patterns. As with my previous post, the idea for this post came about during a discussion concerning the merits of software design. The protagonist of the discussion was of the opinion that Design Patterns are too time consuming to be of use within the field of commercial software development. My intention here is to demonstrate why I believe that to be wrong.

I will not go into any details about the mechanics or implementation of any particular Design Pattern. There are many excellent sources for these available elsewhere.

So getting started then, what exactly is a Design Pattern? Here are a couple of definitions for the term:

Extracted from Wikipedia:
"A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. "

Extracted from Data & Object Factory:
"Design patterns are recurring solutions to software design problems you find again and again in real-world application development. Patterns are about design and interaction of objects, as well as providing a communication platform concerning elegant, reusable solutions to commonly encountered programming challenges. "

Extracted from Data & Object Factory:
"The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral."

So a Design Pattern is a general purpose abstraction of a problem, which can be applied to a specific solution. As software developers tend to solve many similar problems, it makes sense that any software solution would incorporate similar elements from other solutions. Why reinvent the wheel?

Well documented and understood
As Design Patterns are well documented and understood by software architects, designers and developers, then their application within a specific solution will likewise be well understood (although given my reasons for writing this post, I should perhaps add the caveat that they will be understood 'only' by experienced software architects, designers and developers).

Design Patterns gives a software developer an array of tried and tested solutions to common problems, thus allowing the developer to save time by not having to think of a new solution from scratch.

To give an analogy of a Design Pattern from the field of civil engineering (which as I stated in my post Why design is critical to software development has close similarities to software engineering), would be to think of a solution for crossing a river. This is a recurring problem for civil engineers, to which there are a couple of well documented and understood solutions. The civil engineers may build a bridge (of which there are many different kinds, but for the purposes of this exercise, let's just refer to them collectively as bridge), or a tunnel.

Close parallels with civil engineering
Why would a civil engineer try to solve this problem from scratch when there are real world solutions that can be referred to? There are close parallels between the civil engineer solving the river problem, and the software engineer solving a software problem:

• The solutions (bridge or tunnel) are both well understood and documented
• The solutions (bridge or tunnel) solve recurring civil engineering problems
• The solutions (bridge or tunnel) are not deterministic or prescriptive, but are abstract and can be tailored to the specific problem (the bridge or tunnel building materials for example can be selected for their alignment to the specific problem)

The argument against Design Patterns that they are not suitable for commercial use due to their taking too long to implement does not hold up. Design Patterns save time by giving the developer tried and tested solutions to many of their problems.

The only issue I have come across with Design Patterns is that they take time to learn. Some of them can be difficult to grasp and comprehend. However, it is worth taking the time to fully understand them, as they will quickly form one of your greatest assets.

Design Patterns reduce complexity, and therefore the solution becomes easier to comprehend.

Design Patterns are tried and tested solutions, the developer does not need to start from scratch, and can hit the ground running with a solution that has been proven to work (as long as the Design Pattern is being used to solve a similar problem; it would be wrong to expect a bridge to solve the problem of crossing an ocean, where a bridge would simply be unsuitable).

Whilst working as a Senior Software Engineer at Pegasus Software, I got my first exposure to Design Patterns in the work place, not just the theory from books. Much of the software framework used to underpin their products was developed using a variety of Design Patterns, including the Class Factory, Decorator, Template Method and Chain of Responsibility. The resultant code was far easier to comprehend, maintain and extend in the future.

Conclusion
Design Patterns, despite their learning curve initially, are a very worth while investment. They will enable you to develop tried and tested solutions to problems, thus saving time and effort during the implementation stage of the software development lifecycle. By using well understood and documented solutions, the final product will have a much higher degree of comprehension. If the solution is easier to comprehend, then by extension, it will also be easier to maintain.