Click here to Skip to main content
11,480,938 members (58,423 online)
Click here to Skip to main content

Tagged as

Reasons for using design patterns

, 15 Aug 2014 CPOL 5.8K 5
Rate this:
Please Sign up or sign in to vote.
Reasons for using design patterns

Introduction

Following on from a previous article entitled 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 article, the idea came about during a discussion concerning the merits of software design with a work colleague. 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 Patterns. There are many excellent sources for these available elsewhere.

What is a Design Pattern?

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. "

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 types of 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.

Design Patterns give a software developer an array of tried and tested solutions to common problems, thus reducing the technical risk to the project by not having to employ a new and untested design.

Design Patterns may not initially lead to a reduction in development timescales, as there is a learning curve if the team are unfamiliar with them. However, looking further down the development pipeline, once familiarity with them increases, development timescales should gradually reduce.

Close parallels with civil engineering

To give an analogy of a Design Pattern from the field of civil engineering (which as I stated in my article 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 or a tunnel.

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 to hand (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 (when viewed over the lifetime of the application) by giving the developer a selection of tried and tested off-the-shelf solutions which they can tailor to their own specific needs.

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. This is a reasonable criticism, as it therefore requires a more skilled developer to use them. This then may increase the project costs initially. However, when viewed over the lifetime of an application I would fully expect those initial development costs to be recouped due to the lower ongoing maintenance costs due to the higher comprehension and easier extensibility (making the application easier to extend in the future to meet new and emergent opportunities).

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 being used solves 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.

Benefits of using Design Paterns

Design Patterns therefore provide the following benefits.

  • They give the developer a selection of tried and tested solutions to work with
  • They are language neutral and so can be applied to any language that supports object-orientation
  • They aid communication by the very fact that they are well documented and can be researched if that is not the case.
  • They have a proven track record as they are already widely used and thus reduce the technical risk to the project
  • They are highly flexible and can be used in practically any type of application or domain

Conclusion

Design Patterns, despite their initial learning curve, are a very worthwhile investment. They will enable you to implement 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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Dominic Burford
Software Developer (Senior) Marval Group UK
United Kingdom United Kingdom
I am a professional software engineer and architect with over eighteen years commercial development experience, focusing on the design, development and testing of software solutions using Microsoft technologies.

I am a full stack developer with experience of building a wide variety of applications from desktop to client-server to web to mobile and tablet using Visual Studio.

I have experience of architecting scalable, distributed, high volume web applications that are accessible from multiple devices due to their responsive design. I have also architected enterprise SOA solutions.

I have developed enterprise mobile applications for the Android platform using Xamarin delivering real-time data securely to tablet devices via WCF services.

I am proficient in .NET, ASP.NET (VB.NET / C#), Windows and Web Services, WCF, SQL Server, LINQ and other Microsoft technologies. I am also familiar with HTML, Javascript / JQuery, XML, JSON and many other web related technologies.

I am enthusiastic about Continuous Integration (CI) and have setup and configured CI environments from scratch using CruiseControl.NET. I enjoy working in Agile and Test Driven Development (TDD) environments.

Outside of work I have two beautiful daughters. I enjoy cycling, running and taking the dog for long walks. I love listening to music and am a fan of Rush and the Red Hot Chilli Peppers to name a few.

Visit my website here http://www.dominicburford.co.uk
Visit my Github repositories here https://github.com/DomBurf
Follow on   Twitter   Google+   LinkedIn

Comments and Discussions

 
-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.150520.1 | Last Updated 15 Aug 2014
Article Copyright 2014 by Dominic Burford
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid