Kent Beck, along with a hard-hitting one-two punch of a name, has a no-nonsense style and some compelling arguments for the general applicability of the patterns he discusses. As I read, I recognized many of the things I was doing already intuitively, as well as some things that I didn’t. Now, this isn’t a review of Kent Beck’s book; it’s pretty old but far from outdated, and I highly recommend it. But when I finished, rather than finding myself transformed into a pattern slinging power house newly rechristened Tom Tank, I went back to my old styles, some similar to Beck, some not very similar (but I trust a lot of the latter has to do with the fact I’m programming in Ruby, not Smalltalk). The names were too much for me. How to memorize so many magical formulas? If I had to look up every single one, my productivity would be down the tubes, which are already well clogged.
But there is also a simpler, more spiritual reason I reject Beck’s manual. I don’t want to program patterns. I want to program the best, most elegant solution I can, and adhering blindly to an innumerable set of how-tos, which often conflict each other1, is not the way to do that. I can hear the popular kids lining up to deliver the stinging rebuke, patterns were never meant to be applied blindly—there are different patterns for different problems! I agree. In fact, the best patterns are the very general ones, which offer more gentle nudges in the right direction than hard set rules. Have a method with a lot of nested conditionals an arguments? Maybe it’s doing too much. Maybe help it break up, expand, seek new horizons, see other people. Sure. But the best pattern is still the most useful: do what makes sense. I’m not being sarcastic, you wouldn’t believe how many programmers seem on doing the opposite of what makes sense. It’s as if they think that taking the time to think about it would delay their paycheck.
The more general patterns get, the more useful they get, until they are the One Pattern mentioned above, which rules them all. The more specific they get, the weaker and more contradictory they get, until you have some sort of cut out code commandment like No more than 10 lines per method. At best, a pattern like that is going to be based on averages. As in, on average, the best constructed method for any purpose has about 10 lines. The best method for some purposes may have 20 lines, and for others it may only have one line, so if we max out at 10 then we can’t go too wrong. The problem with this is, just because you’re doing no worse than average, doesn’t mean you’re writing all that great of code. Or even worse, you can never use conditionals at all, as I’ve heard suggested recently around here. If there’s a point that this all boils down to, it’s that the usefulness of patterns asymptotically approaches zero along the axis of code passion. I think patterns should be treated as categorically different than, say, syntax errors. When you’re writing a sentence, you must end it with a period, but how many commas you use is up to you. Some people will try to give you a list of the places where and ONLY where you can use a comma. This is a useful guide for beginning, or average writers2. But if you want to be a great writer, eventually you’ll disregard all of those rules at one point.
1 Beck actually discusses this problem in a pleasing tongue in cheek manner in one section, but I trust we’re all adults, cognizant of the fact we’re in a slime-fest here, out for blood.
2 Ironically I think I may have overused commas in this article. In fact, that’s what made me think of it.