What’s wrong with Design Patterns ?

I’m a big fan of design patterns, they do make my work easier, more explicit, more maintenable and also more enjoyable; however I’m surprised that not everyone knows them and actually uses them. What’s wrong with design patterns ?

Some facts:

  • they are difficult to learn and to teach, it is nearly impossible to teach design patterns at school unless students already have significant hands-on practice of software development, unless they already encountered real-world problems
  • they are difficult to implement correctly when you start with them, you often misuse them at first tries
  • they do not match the way many people think about software, many people still resist to them, they think using design patterns is counter-intuitive (this is especially true if you started your carrer with a procedural point of view, how many times people tell me: “using patterns or not, it is the same at the end of the day in the software !”)
  • once you know them, you are impressed at the power and expressiveness they give you, so you tend to overuse them

Since I’m still convinced design patterns MUST be known by any professional developer today, what are the best ways to learn or teach them ?

  • There is no magic answer, however these are some clues:
  • mentoring is undoubtedly the best way to learn design patterns; so the best way to learn them is to find coworkers that know them more than you do; it is even better to work on the same part of the software to really get the point in using, -or not using- patterns (pair programming ?)
  • If patterns have to be taught in a classroom environment to people that already have work experience (as in company internal training sessions), it is worthless to describe and explain the catalog of patterns, you’d better explain what you found difficult or confusing when you were learning them, this is much more valuable for your audience. For instance, explain that the intent of a pattern comes first, that yes it is normal that the UML diagrams may be the same for two or three patterns, because their intent is different, that yes they are already using some patterns without even being aware of it… I think presenting patterns through refactoring examples should also be very relevant since the value-added of patterns is more obvious.
  • Maybe design patterns are too abstract to be learnt directly (1); as usual when abstraction is a problem, we should then focus on more concrete examples (or instances). In the case of design patterns, more concrete examples may be J2EE patterns (it is very surprising to see that many people know much more about J2EE patterns than fundamental GoF patterns !), or Analysis Patterns that derive from design patterns and that solve a particular domain problem. Once the apprentice knows enough such concrete patterns, it becomes easier to describe the abstract pattern that sums them all.

(1) Actually one strength of design patterns is that they are abstract enough to be reusable to a great extent.

Initially published on Jroller on Monday April 25, 2005


Software development, Domain-Driven Design, patterns and agile principles enthusiast