As you progress in your software development career, one of the terms you may start to hear from seniors and architects or read about are “design patterns”. Design patterns, more than likely, were not part of any of your college classes – or at least they weren’t for me. In my upcoming articles, I will be covering different types of design patterns we use today in C#, but first, let’s start with an introduction.
Chances are, the programming problems you try to solve today have already been solved many times before and there may even already be a name for its solution. Design patterns are known approaches to software design that help solve a common problem, improve maintainability, and hopefully speed up development. That’s why it is so worth getting to know existing design patterns. Work smarter, not harder. You don’t always have to reinvent the wheel.
A Little History
Before we dive deeper, let’s start with a little history of how this all came about. Software design patterns became popularized in the 90’s after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 by the “Gang of Four” – Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
Gang of Four Design Patterns
There are 23 Gang of Four design patterns grouped into 3 categories:
- Behavioral
- Interpreter
- Template Method
- Chain of Responsibility
- Command
- Iterator
- Mediator
- Memento
- Observer
- State
- Strategy
- Visitor
- Creational
- Factory Method
- Abstract Factory
- Builder
- Prototype
- Singleton
- Structural
- Adapter
- Bridge
- Composite
- Decorator
- Façade
- Flyweight
- Proxy
You may have seen some of these names used in applications you’ve worked on and didn’t realize they were based on a pattern approaching 30 years old!
These aren’t the only software design patterns and some listed here are more commonly used today than others. However, I would say these from the Gang of Four are definitely the classics in object-oriented development.
In addition to not having to reinvent the wheel for common problems – another benefit in knowing these patterns is that it’s easier communicate with other developers. It also helps when reviewing code written by others when you recognize a pattern and can understand what the intent was. For example, if I see a class with the name “___Factory” in it, I know immediately what that class probably does. This helps because, how fun is it when you have to review code that you don’t understand?!
I hope this gave you a good introduction to software design patterns. My goal is to make design patterns simple and easy to understand! Stay tuned for my upcoming article on the Strategy pattern!