Design Patterns

2007-05-17

There’s a far more subtle danger to design patterns, though, a hole into which I’ve fallen many times. When you approach a programming problem and know your patterns very well, the likelihood that one of them raises it’s head and shouts “Use me! I’m ideal in this situation!” is fairly high. Realizing that some problem fits a pattern can be almost the same thing as understanding the problem.

Just now I wrote that a problem fits a pattern. That might seem odd at first sight, after all, patterns are about solutions, not problems. Surely you need to understand the problem first, and only then think of solutions which may involve the use of a pattern. Right?

Well, yes… and no. The thing is, in my experience it happens quite often that you simultaneously grasp the nature of a problem and think of the patterns that you can use to solve it.

Here’s a theory of how that could work: As a programmer, you usually quite automatically break the problem you’re trying to solve down into successively smaller portions, small enough for it to be “obvious” how to handle them (and when you can’t do that, you find the problem overwhelming). Knowing how to handle each of these smaller portions implies that they’re something you’ve encountered before, something you’re familiar with – in other words, a pattern. Thus solving a problem becomes synonymous with breaking it down into patterns you know how to handle.

I find it fascinating how our minds manage to do that, sometimes even without us consciously realizing what’s going on. On the other hand, this very likely this type of processing that makes us incapable of coming up with anything truly new.