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