This is my response to the popular notion that the twenty-three Gang of Four design patterns are useful. In interviews, in book clubs, in architecture discussions, we say "design patterns" and nod sagely to each other. "Yes, the wisdom of our elders. We all should strive to meet the ideals of the Patterns of Design."
Well, I think that's bunk. I think most of those design patterns are obsolete, or unnecessary. If I got a pull request to add a design pattern to my codebase, I would probably reject it.
Please, pick a pattern and see if you disagree!
A Factory is a class used to instantiate other classes, hiding the messy details of that class's construction from the client code. The factory may even hide the concrete type of the constructed class from the client code. For example, ButtonFactory.CreateButton() may return an AbstractButton.
The Abstract Factory pattern layers more complexity on top of that. Not only do you not know the concrete type of button, but you won't even know the type of the Factory. For example, an AbstractButtonFactory may be a WindowsButtonFactory or a MacOSButtonFactory.
But, at some point, the AbstractFactory needs to be instantiated. At that point, the type is known. What is gained by hiding the type afterwards?
Show me an application that uses an Abstract Factory, give me a few minutes, and I'll show you a simpler application, with identical behavior, that doesn't.
Rating: 1/5 do not use
A Builder is a class used to instantiate other classes, hiding the messy details of that class's construction from the client code. It could be used to control the order in which properties are instantiated, or prevent certain combinations of properties.
Constructors can also do these things. So can factories.
Consider BicycleBuilder.WithHeight(29).WithColor("red").Create();. What has been gained over new Bicycle(height: 29, color: "red");?
Rating: 2/5 do not use
A Factory is a class used to instantiate other classes, hiding the messy details of that class's construction from the client code. It can also be used to instantiate dependencies meant to have a limited lifecycle, which could not otherwise be injected into client code.
This is useful.
Rating: 4/5 use sparingly
A Prototype is an object used to instantiate other objects, by cloning itself.
Just create the new objects. Use a Factory if it helps.
Rating: 1/5 do not use
A Singleton is a class which can only be instantiated once. Client code would call FooSingle.GetInstance() rather than new FooSingle().
This does not solve any problem that could not be solved with a properly-scoped variable, static class, or Lazy<T> initializer.
It introduces new problems, in that its scope is no longer clear. Testing and debugging are also made more complicated, although that also applies to global variables and static classes as well. That's why we try to avoid them.
Rating: 1/5 do not use
An Adapter is a class that wraps around another class. Perhaps the adapter conforms to an interface that the original class doesn't quite implement. Perhaps the adapter hides details of the original class that don't matter for a certain client. Perhaps the adapter is easier to mock out for testing purposes.
Adding an adapter layer is, by definition, more complicated than not adding one. But that complexity in structure can easily pay off in making the client easier to write.
Rating: 5/5 apply as needed
A Bridge is, as far as I can tell, an Adapter. I've spent 2 whole minutes on the wikipedia page and I can't tell what the benefit is supposed to be.
This phrase jumps out though: "A compile-time binding between an abstraction and its implementation should be avoided so that an implementation can be selected at run-time".
Why? When don't you know the implementation at compile time? Why would you need this flexibility?
Rating: 1/5 use Adapters
A Composite is a class that encapsulates multiple objects, allowing them to be treated as one object. Client code only needs to talk to the Composite, which will delegate calls to all of its child objects. Composites may even delegate to other Composites, forming a tree structure.
Adding a Composite layer is, by definition, more commplicated than not adding one. I rarely see a need to create a custom tree structure to represent multiple objects, and I don't think a Composite that is just a list can justify its complexity compared to a plain old List.
Rating: 2/5 do not use
A Decorator is an Adapter that implements the same interface as the wrapped class, and forwards all calls to the wrapped class, but performs some additional functionality before or after doing so.
That additional behavior could be logging, timing, or calling some additional method. Since the interface is the same, Decorators can be layered.
Rating: 2/5 neat but let's call it an adapter
A Facade is an Adapter, but with the stated goal of exposing a simpler interface than the wrapped class.
What, do most Adapters expose more complicated interfaces?
Rating: 1/5 call it adapter
A Flyweight is a class that helps reduce the memory used by a collection of objects, by holding data common to those objects in a shared structure. The classic example is a text editor: Naively, each instance of the letter "A" in a document might hold its own copy of font outline, font metrics, and other formatting data. Applying the Flyweight pattern, each instance would hold only its position in the document, and a single copy of the bulky font data would be stored in the Flyweight.
Are you writing a text editor? No? Keep your objects simple and skip the Flyweight. Memory is cheaper than it was in 1990.
Rating: 1/5 do not use
A Proxy is an Adapter.
Rating: 1/5 it's an adapter
A Chain of Responsibility is a collection of objects that can handle client requests. Each object may choose to handle a request itself, or pass that request on to the next object in the chain.
This could be used to implement a throttle or retry policy, with the last link in the chain being the "actual" handler. Or perhaps different requests need to be handled in different ways, and each link could handle a specific request type.
You know what else can handle different requests different ways? A switch statement. Keep it simple.
Rating: 2/5 avoid if possible
A Command is a request or event that contains instructions on how it should be handled.
Why? If you're passing data around, pass data around. Keep the handler logic in the handlers.
Rating: 1/5 do not use
An Interpreter is a program that can execute other programs written in a custom language.
A custom language? Really?
Rating: 0/5 get out of my sight
An Iterator is an class that exposes properties of another class, sequentially.
This is built into modern languages. Even the dustier languages have for and while.
Rating: 1/5 do not use
A Mediator is a class that coordinates communication between other classes.
Just have your other classes communicate with each other.
Rating: 1/5 do not use
A Memento is a class that holds the internal state of another class. When the other class changes, the Memento can be used to roll it back to a previous state. This could be used to build a sort of transactionality, or an undo function.
This pattern attempts to mitigate the difficulty of managing objects with complex, mutable state. By adding more complexity to them. Instead of making them less stateful.
Undo functions can also be written as a stack of actions & their reversals. I would argue that this maps more closely to the semantics of "undo": undoing an action, versus restoring a state. Besides, are you writing a text editor, that you need an undo?
Rating: 1/5 do not use
An Observer is a class that reacts to changes in another class. The observed class might have a collection of Observers, and notify each of them in turn.
This a pub-sub system, at the object level. It's conceivable that a single application might become large enough that an Observer collection would be more practical than the observed class explicitly sending the required notifications. Conceivable... but not common.
An unpleasant side effect of the extra layer of abstraction is that a developer making changes to the observed class cannot easily tell where those notifications will go - or even if they go anywhere at all. So, pretending that the Observer and observed are not tightly coupled actually makes the code more difficult to maintain.
Rating: 1/5 do not use
State is a fundamental concept. Every nontrivial program has state (yes, even if it's hidden by monads or whatever).
Rating: 3/5 yes but why
A Strategy is a class that contains an algorithm. A program might have multiple Strategies for solving a problem, and pick which one to use at runtime.
One example given by Wikipedia is a validation library, which can be re-used across a system, by selecting different validation methods based on the type of data, the source of data, user choice, or other factors. This sounds like a terrible idea. Skip the Strategy Pattern, and just write the needed validation where it's needed.
Another example given by Wikipedia is a billing Strategy, that might be used to calculate prices differently during happy hour. That's just called a lambda. Or better yet, if the rule is as simple as "half price during happy hour", an if.
Rating: 1/5 do not use
A Template Method is a function in a base class, which calls other "hook" functions in that class, as steps of some algorithm it is attempting to follow. Inheriting classes may override the hooks, customizing the behavior.
This requires every implementor of an inheriting class to first read the base class, in its entirety, to understand each of the hooks and its purpose. Often, the Template Method's original author will fail to provide a hook that some inheriting class needs. Or perhaps provide too many hooks, with some of them never overridden by any inheriting class.
This makes the Template Method a very poor abstraction, most of the time. It doesn't make writing future code easier, and it does get in the way.
Rating: 1/5 just declare an interface
A Visitor is a class that performs some action on each object of a collection. Normally those objects might perform actions themselves, but perhaps the Visitor has some functionality that doesn't really fit into those objects.
For example, a video game may have a collection of actors: players, enemies, items, etc. Each of these knows how to interact with each other, but none of them know how to interact with the save system. The code to iterate over the objects in the game's state, in order to export them to a save file, might live in a Visitor.
Rating: 2/5 useful but complicated
Well, I don't fully agree with that.
On the one hand, yes. There are millions of things I don't understand, from word processors to cars to the United States' healthcare system. And lots of those things are useful, even if there are better alternatives.
On the other hand, the point of Design Patterns is to make things easier to understand. Their explicit goal is to make software easier to implement, change, test, and reuse. How can it be easier for me to implement my application with a Bridge, when I just don't get what the Bridge is for? How can it be easier for me to change an application written with Observers, when the existence of Observers is a barrier to my understanding the application's behavior?
This is my overarching point. Most software is written once and read many times, so when writing we should be as kind as possible to the future readers. In my opinion, one of the best ways to do that is to avoid unnecessary layers of abstraction. It's fair to require them to read the code they're about to modify; I believe it's unfair to also require them to read a book first.
I am a full-stack .NET developer. I write web services, windows services, and websites. Sometimes utility-style applications, usually without a GUI. I write C#, SQL queries, CSS, and XML transforms. I do not write libraries used by hundreds of thousands of developers.
The disclaimer here is that my experiences are not universal, and my advice will not be applicable to all software, or all software developers.
$Pattern to great effect in my application!Cool! I believe you, especially if that application was not the kind I write for my job. Again, I don't usually write large applications with complex UIs, or graphics drivers, or high-performance libraries. So my opinions stated here probably don't apply to your application.
In fact, I'd love to hear about it! Send me an email, or an IM, or open an issue on this repo. It's kind of hard to learn about these patterns from the toy examples people tend to blog about.
That would be unnreasonable, wouldn't it? No, I'm not suggesting we should remove design patterns from all software. I am saying that, when I build an application, I prefer to frame the process as "How can I solve this problem?" rather than "Which design pattern can I use here?". In fact, I'm betting you do, too.
$Pattern, and I'm glad they did!Really?! I especially want to hear from you. Please do reach out!