When it comes to solving a problem in software, there can be as many potential solutions as there are developers. But many times there is a given solution that just works for that situation. Now, wouldn't it be great if there was a collection of these common solutions, and it was structured in such a way that it could work for a lot of different software paradigms? There is, and they even wrote a book about it.
Design Patterns, Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, is exactly that book, and it should be considered the go to reference for any object oriented software developer. The subject of the book, (which, btw, is commonly referred to as the GOF (Gang of Four) design reference), can simplify any good developer's job and promote interoperability between software groups.
(But first let's give credit where credit is due. The prevalent MVC Design Pattern, which predates the GOF patterns, can be found in an earlier programming language, Smalltalk. Smalltalk was created by Alan Kay and the research team at the Xerox Palo Alto Research Center. Now, if that name sounds familiar, it might be because this was the direct inspiration for Apple's first Graphical User Interface (GUI), and today we are still using products built upon their work. No wonder Alan Kay was fond of saying, "The best way to predict the future is to invent it". Truer words were probably never stated.)
The GOF Design Patterns were built upon three categories, as follows:
- Creational Patterns: Patterns that deal with the creation of objects and classes.
- Structural Patterns: Patterns that deal with the composition of objects and classes.
- Behavioral Patterns: Patterns that deal with the communication between objects and classes.
Let's take a look at what comprises each of these Design Pattern categories.
Factory - A factory object is responsible for creating an object without exposing the instantiation logic. Instead you will find a common interface, making it easier to implement. This is also implemented as a factory method, which allows the subclass to depict the class to be instantiated.
Abstract - An extension to the Factory pattern, abstract patterns allow related or dependent classes to be created without defining the underlying concrete class.
Builder - The concept behind the builder pattern is to separate the object construction from its representation. This would allow for the same construction process to create objects with different representations.
Singleton - Of all of the creational design patterns that exist, I believe that, in a object driven project, a singleton can be the most useful if used correctly. A singleton object ensures that there can only be one instance of that object, and every call by the different objects in the project always communicate with said instance.
Prototype Pattern - A prototype is an object that is fully instantiated, but exists to be copied or cloned.
Adapter – The Adapter pattern matches the interfaces of different classes.
Bridge – The Bridge pattern separates the object's interface from its implementation.
Composite – The Composite pattern incorporates a tree structure of simple and more composite objects.
Decorator – The Decorator pattern allows objects to be "adorned" dynamically with new responsibilities.
Facade – The Facade pattern is a single class that represents a complete subsystem.
Flyweight – As you would expect, the Flyweight pattern is a very specific object designed for quick, efficient sharing.
Proxy – The Proxy pattern sets up the creation of objects that are designed to represent other objects.
Chain of Responsibility – The Chain of Responsibility pattern allows for the movement of requests between a chain of objects.
Command – The Command pattern defines the encapsulation of a command request as an object.
Interpreter – The Intrepreter pattern allows for the inclusion of language objects in an object oriented system.
Iterator – The Iterator pattern allows for the sequential access of objects stored in a collection.
Mediator – The Mediator pattern sets up simple communication between instantiated classes.
Memento – The Memento pattern covers the archiving and retrieval of the internal state of a given object.
Observer – The Observer pattern allows for notification of change to any number of attentive classes.
State – The State pattern defines a behavior change when that object's internal state changes.
Strategy – The Strategy pattern allows for the encapsulation of a defined algorithm inside of an instantiated object.
Template Method – The Template Method defines a specific steps for an algorithm while allowing a subclass to control some steps without changing the algorithm's structure.
While each of the GoF Design Patterns above deserve their own conversation, it is easy to see how applying the concepts of design patterns can make an object oriented development project easier to implement. In fact, many of the patterns will no doubt look familiar to most developers, even if they are unaware of their origins. For example, Microsoft's iEnumerable class is an excellent example of the Iterator Pattern.
Naturally, the Science of Design Patterns continues to grow with technology and its implementation, with new patterns coming into use all the time (for example, SOA Design Patterns). But by implementing the ideas set forth in the GoF design patterns, it not only allows for clean code that is easier to follow, but also sets up the entire project for future adaptability. And that makes the effort to learn design pattern methods a bargain.
Software Design Pattern
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. So patterns are formalized best practices that you must implement yourself in your application.
Share and Enjoy