Why OO patterns are not for the weak

The standard mantra for many programming evangelists is "use design patterns, they combine the wisdom of years for you to use" (in case you don't know what patterns are, read the Wikipedia article). Some of my recent adventures into the patterns world have convinced me that while patterns do contain much wisdom, they are not the solution to the average programmer. Why is this?
Design patterns help you model your real world object model into OO terms and avoid pitfalls such as tight coupling and unmaintainable code. That's great. But the problem? Proper use of the patterns requires so much preknowledge that the average programmer very easily stumbles on them. Certainly you can factor your real world application into some nifty classes, apply some Bridges, create Flyweights and throw in some Proxies for good measure. And then? Perhaps your code now adheres to some patterns – but it's not too likely to be much more maintainable: patterns are just new ways to play with toys you didn't understand properly in the beginning anyway.
Patterns come from the world of building architecture where they were considered extremely useful. Use of patterns in an all-professional environment is quite different from the current programming world. You can easily get a B.Sc level examination without actually knowing how to design an OO system. Now this is the problem we should be addressing!
Despite everything above, I'm by no means saying patterns are evil. Common terminology is good, and they do provide a valuable canonicalization for certain common phenomena in the software engineering field. However, they do remind me of software development processes: Once you're competent enough to really understand them, you realize you've arrived at most of the conclusions yourself.

June 3, 2005 · Jouni Heikniemi · Comments Closed
Posted in: Misc. programming