Design Patterns: Coding Like a Rockstar
Michael Samuel, Accusoft Software Engineer III
Introduction: Gang of Four
Object Oriented Programming (OOP) and alcohol don’t mix; Please don’t drink and derive! 😉 Now that my public service announcement is over, let’s dive into the design pattern ocean. Way back in 1994 (when I was saving the world from evil… on my Sega Genesis), there was a book published called, “Design Patterns: Elements of Reusable Object-Oriented Software” written by four authors: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. I presume the book’s long title required people to deeply inhale before reciting it and thus the four authors and the published work are interchangeably known today as the “Gang of Four” (GOF) colloquialism.
What Are Design Patterns?
From the dawn of software, developers have faced the same problems and have solved them with some creative (and not so creative) ways. Design patterns are general solutions to common recurring problems in object-oriented software design.
What Are the GOF Design Patterns?
There are 23 quintessentially defined design patterns (see list below) that are used in their own rite or as the foundation for others. They are broken up into three groups: Creational, Structural, and Behavioral. First, Creational Patterns are about creating objects by instantiating classes. Next, Structural Patterns define ways for new functionality when composing objects. Finally, Behavioral Patterns are primarily focused on communication between objects.
Why Use Design Patterns?
There are many benefits to using design patterns. First and foremost, it’s just plain cool and you will gain RockStar status among your peers! Let me explain further…design patterns (when applied correctly) will make your code robust and give it a high level of sophistication with the following qualities: efficiency, reusability, maintainability, learnability, and communicability (say that five times real fast). They are also tried and true ways of coding used by many of developers (whether they know it or not). Just imagine explaining to another developer how some piece of code is working; Is it more succinct to say that a “Template Method Pattern” is used or “Here we have multiple algorithmic steps that can be overridden by subclasses that will allow different behaviors and yet still ensure that the overall algorithm is still followed”?” Whew, I see a clear winner! Also on the same note, if the developer wanted to better understand all or some of the concepts, they could always research the design pattern on the internet and find many examples from which to learn.
Stay tuned for future blogs that will detail each of the patterns below:
Creational Patterns – Object Creation
|Abstract Factory||Create objects from related “family” of classes.|
|Builder||Construct an object step-by-step.|
|Factory Method||Create an object from a set of classes.|
|Prototype||Create new cloned object of an existing object.|
|Singleton||Create only one object instance of a class.|
Structural Patterns – Object Composition
|Adapter||Link different classes by matching interfaces.|
|Bridge||Separate an object’s implementation from its interface.|
|Composite||Recursive hierarchical tree of related objects.|
|Decorator||Modify an object’s functionality dynamically.|
|Facade||Single class simplifying a complex subsystem.|
|Flyweight||Object sharing data with similar objects for efficient memory use.|
|Proxy||Surrogate object to control access to an another underlying object.|
Behavioral Patterns – Object Communication
|Chain of Responsibility||Pass sender request between chain of receiver objects.|
|Command||Encapsulate list of requests as an object.|
|Interpreter||Define grammar representation instructions.|
|Iterator||Traverse elements of a collection.|
|Mediator||Encapsulates how a set of objects communicates.|
|Memento||Capture then restore object to a previous state.|
|Observer||Object that notifies subscribing objects to its change of state.|
|State||Dynamically alter an object’s behavior upon internal changes.|
|Strategy||Encapsulate a set of run-time interchangeable algorithms.|
|Template Method||Define basic algorithm that a subclass may override.|
|Visitor||Add new operations without modifying class.|