Design Patterns: Best Practices for Application Development

Whether you’re building a website, web app or mobile app, the success of the project will hinge on how well the developer can meet the project requirements. For larger projects, there could be a team of developers that must work together to achieve their goals.

Developing in a complex environment is one of the primary reasons why the concept of design patterns was initially introduced. Design patterns are solutions to software design problems that occur consistently in real-world application development. These patterns present a reusable framework of designs and interactions of objects.

One of the aspects that I like about design patterns is that for a developer to even grasp the value of using such a construct, they will have to have attained some level of sophistication with how they think about code. Having applied design patterns in software projects means that they both care about constructing an optimal OOP relation to solve a problem gracefully, as well as have resisted their own temptation to code something up out of their own mind.

I often use this observation to evaluate the developers that I hire, and have had great success evaluating how developers think about coding. There are very few problems which cannot be decomposed into one or more applications of those 23 design patterns. With over 20 years of development experience I continually look for opportunities which may expose a yet undiscovered design pattern, but I cannot say I have found one that generalize as well as these.

Design patterns provide a common platform and a standard terminology for developers. When developers are using a singleton design pattern, their teammates will understand that a single object is in use.

As design patterns have evolved over the past 20+ years, they’ve become best practices for common development issues. Becoming aware of design patterns can also introduce these best practices and assist less experienced developers learn software design in a more efficient and collaborative way.

The concept of design patterns in software development was originally presented in the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software. The book was written by four authors who are now known collectively as the “Gang of Four”.

Regarded as an important source for object-oriented design theory and practice, the book has become highly influential in the field of software engineering. The first two chapters of Design Patterns is focused on exploring the capabilities and pitfalls of object-oriented programming. The remainder of the book describes the 23 software design patterns.

The 23 patterns developed by the Gang of Four are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral.

The origin of design patterns tells us a lot about why they exist. In the 1970’s, out of the famed Xerox PARC days, arose an object-oriented-programming language called Smalltalk which was very influential on all subsequent programming language’s design.

The level of abstraction now possible provided the ability to create various relationships among objects. In the 1990’s when object-oriented programming languages were widely available, there were many ways you could construct objects to do things that accomplished a task, with little consensus about which way was best.

It subsequently became apparent that many software design problems exhibited the same issues repeatedly, and that developers should not need to re-invent the wheel every time. Out of this came the Gang of Four’s 23 common object-oriented problems and solutions which are now universally referred to as design patterns.

I think it’s obvious why we should use design patterns, for the same reason we should “stand on the shoulders of giants”, which is to leverage great inventions/solutions others have produced before us. But this is such an intangible aspect which is not overtly visible, it is not a customer facing deliverable or even a task in a development project, it’s the correct application of solving problems in the art of computer programming.

However, the lack of applying successful patterns will surely be visible as the effect of increased development time/effort/cost/bugs/rework and the inability to easily adapt to changing customer requirements.

Design patterns are an excellent tool to not only help developers work in a cohesive framework, but they’re a great resource for identifying coders for your team. They’ve become a large a must-have part of our process here at Azavar Technologies and a key to our success.

23 Gang of Four Design Patterns

Creational Patterns
Abstract Factory Creates an instance of several families of classes
Builder Separates object construction from its representation
Factory Method Creates an instance of several derived classes
Prototype A fully initialized instance to be copied or cloned
Singleton A class of which only a single instance can exist
Structural Patterns
Adapter Match interfaces of different classes
Bridge Separates an object’s interface from its implementation
Composite A tree structure of simple and composite objects
Decorator Add responsibilities to objects dynamically
Facade A single class that represents an entire subsystem
Flyweight A fine-grained instance used for efficient sharing
Proxy An object representing another object
Behavioral Patterns
Chain of Resp. A way of passing a request between a chain of objects
Command Encapsulate a command request as an object
Interpreter A way to include language elements in a program
Iterator Sequentially access the elements of a collection
Mediator Defines simplified communication between classes
Memento Capture and restore an object's internal state
Observer A way of notifying change to a number of classes
State Alter an object's behavior when its state changes
Strategy Encapsulates an algorithm inside a class
Template Method Defer the exact steps of an algorithm to a subclass
Visitor Defines a new operation to a class without change