An anti-pattern rant

This post is not about anti-patterns, rather it is itself anti-pattern. I am railing against the ubiquity of patterns because I believe that, in many cases, their fundamental message has become lost in the midst of an unthinking, cultish devotion to the "patternal" (to coin a phrase) doctrine.

First, a couple of anecdotal items to illustrate where I'm coming from.

• ITEM: Recently, I attended a job interview. During the interview, I was asked about design patterns and the GoF book. Yet at no point was I asked about the wider topic of object-oriented design in general.
• ITEM: In a previous job, I worked under a technical lead who consistently exhorted his minions to consult the GoF for every design decision under the sun. Not once was discussion initiated from a standpoint of the principles of good design.

Okay, so this is nothing like a statistically significant sample of the programming universe, I know. But equally, conversations with my peers suggest that these are not uncommon phenomena.

So what is the problem, exactly? The problem, as I see it, is akin to one of stalled shu-ha-ri. The GoF book has been very successful at encouraging developers to consider the implications of their design choices. It contains concrete implementation details, which make it easy for developers to apply each pattern. But that very ease of application has also, I suspect, stymied deeper thought for many developers about the underlying justifications for patterns. In particular, I think that some programmers develop blind spots around the edges of the patterns that they apply to their code.

I've seen a number of cases where patterns from the GoF have been applied inappropriately. The best of these cases merely introduced unnecessary complexity. The worst cases actually led to serious issues of rigidity, fragility and immobility in the surrounding code. Clearly patterns are not a panacea, yet I've seen them used that way, as if by rote. Of course, this reflects a failing of the developer(s) concerned in each case, not a failing on the part of the GoF. But my concern is that the GoF patterns make traps like these easy to fall into.

Patterns are (or should be) a means to an end, not an end in and of themselves. Instead the end should be a design that is flexible, robust and reusable. Perhaps that sounds easier said than done, but it is the natural consequence of adhering to the five SOLID principles of object-oriented design, collectively popularised by Uncle Bob.

In a recent, unscientific straw poll of eleven of my peers, only two of us were familiar with the SOLID principles, yet all eleven were familiar with the GoF book. This state of affairs worries me greatly.

Briefly, the five SOLID principles are as follows.

• Single responsibility principle: Every class should have exactly one reason to change.
• Open-closed principle: Bertrand Meyer's paradigm-defining assertion that classes "should be open for extension, but closed for modification". That is to say, new behaviour can be added to a class without needing to modify it.
• Liskov substitution principle: Derived classes must be substitutable for their base classes. Everything that is true of a base class must also be true of its derived classes.
• Interface segregation principle: Classes should provide separate interfaces, according to the sets of methods that are required by their clients or client groups.
• Dependency inversion principle: Dependencies should be on abstract interfaces, rather than on concrete implementations.

These are the principles that underpin all good object-oriented design, including the patterns in the GoF book. And it is these principles that should be a lingua franca in design discussions, regardless of the specific programming languages involved. Of course, the GoF patterns can and should still be used where they are suitable. But they should be used within a framework of understanding the design principles on which they are based.