Unusable
And here we get to the final failing. All software design patterns have a problem caused by the structure of their presentation. They manage to neither provide education to beginners nor the ready reference of solutions they purport to be.
Beginners in a subject are unlikely to understand the contexts in which the pattern arises. Most patterns presented take little time to explain the context and forces because they are solutions first. But the trouble beginners have is often the need for more insight into what their problems are. This gap is the reason why design patterns remain both overused and underused by those new to programming.
A beginner needs hand-holding through specifics, and patterns aren’t about specifics. Someone picking up a design pattern needs counterexamples to know what a pattern does not warrant or require; otherwise, you end up with cargo cults.
But even when you are experienced, and even when you do know what pattern you
are looking for, they can be difficult to use well. This is because, again,
they are presented in the final form rather than as a process to reach it.
Having a solution to review is inspirational rather than educational. Having a
problem worked through is a much more powerful lesson. For experienced
developers, a solution can be enough. But even for the most seasoned, if they
are in a rush, it can be tiring to take on the additional cognitive load of
converting it into a plan of action. The book
What were the original software design patterns documented for? One purpose may have been to show elegant final forms. This noble goal was likely the main driver behind the patterns in the GoF book[GoF94]. However, I strongly suspect many other patterns were documented, intentionally or innocently, as a form of self-promotion or plumage of developer prowess. We will see later how this ego-driven aspect is at the core of many pitfalls in design patterns, software and otherwise.