Don’t Use Design Patterns!
Don’t Use Design Patterns, but Know Them — Master Them!
Behind this catchy title (sorry) lies one of my dearest pieces of advice, nurtured by unfortunate experiences with enthusiastic young developers that had just learned about patterns after a training session. How many times have I reviewed lines of code littered with useless classes and cluttered with pointless abstractions? I don’t know. (And I probably don’t want to know.)
Never, never try to put design patterns in practice. Never try to include them into the design of your new application. Don’t engage in aggressive refactoring to add patterns in any existing code for the sake of “making it look better,” or for the sake of flexibility, “so the code will be easier to update in the future.”
However, study them, understand them, re-read them, think about them and give them some attention.
The metaphor game
If I were a pianist
Design patterns would be my scales. Scales develop finger nimbleness and train the spirit. Pianists have to know them and compose with them, but scales aren’t anywhere close to masterpieces, they aren’t music.
Imagine the surprise of the audience if, during a performance in a trendy auditorium, they read in the middle of a program, “Major scales played on a 3-beat rhythm followed by a playful syncopated minor scales inventory.”
Similarly, if a composer went through the Moonlight Sonata to refactor the piece, inserting a bland C# scale to ease the cramps of the interpreter’s fingers, well, that would be the most terrible answer to a false problem.
If I were a chess player
Design patterns would be the problems I solve scanning the newspapers, magazines or dedicated books: These puzzles highlight tactical aspects of the game such as deflection, pin, decoy, passed pawns, sacrifice, overloading…but they aren’t the game, they are just a tool that helps me learn a subset of chess. I couldn’t become a grand champion if I only studied tactics.
Of course, being a great tactician helps. Knowing tactics help you find solutions you’d otherwise be oblivious to. But if all you tried to do during your games were to sacrifice your pieces for no reason beyond the fact that it is a tactical aspect of the game (and yet one of the most brilliant ones), you’d end up being a terrible chess player — and we wouldn’t call your style romantic, just plain dumb.
No more metaphors
Design patterns are fantastic when correctly put into practice. They help us when they are an additional source of inspiration but not a destination, not an end.
Design patterns let developers discuss possible solutions to common problems. These patterns demonstrate simple study cases that are easy to understand and easy to put into practice into your more substantial project, into real life designs. Put together, they form architecture catalogs that will welcome beginners and experts alike. They train us on specific and diverse aspects of object-oriented programming.
Each pattern ought to be used if and only if it fits the problem at hand. Not keeping this in mind will make our code sick and we’ll soon see known diseases such as “Singleton-aches,” along with “OnlyTheFormerDeveloperKnowsAboutThisObfuscatedCode.”
A pattern is not a defined and immutable solution. A pattern is by no means an implementation. A pattern is a way out of a problem. A pattern explains how to overcome common hurdles you’ll find on your path. Don’t let patterns guide you. Don’t see your current problems from a pattern perspective. Don’t seek to transform your problem so it fits your pet pattern, or you’ll end up writing mediocre solutions to problems you didn’t even have.
KISS — Keep It Simple, Stupid.
The most elegant solution is the simplest one, the easiest to understand.
Not a single “Hello World” example justifies the use of a pattern, and no “Hello World” example corresponds to a user need. If I’d like to complicate things, I’d say that Hello World has become a pattern in itself — its sole purpose is to give a glimpse of new technology to developers. You don’t teach developers a new technology exclusively using, “Hello World!”
If a problem has two solutions, one that fits in ten lines of code, and another one with hundreds of lines of code along with a pattern, please consider not using the pattern. Their presence isn’t a quality measurement.
Of course, if your program is littered with the same ten lines scattered around, it might be time to reconsider.
But if…
Never develop for “if something happens…” Develop because of your current problem. Developing for a blurry hypothetical future is the best way to transform a two-day project into a two-month project. If you happen to justify the presence of a pattern in your code only through a “you know, if…”, then remove the pattern.
So, what’s your opinion?
