| When I first began learning patterns, they represented a flexible, sophisticated, even elegant way to do object-oriented design that I very much wanted to master. After thoroughly studying numerous patterns and pattern languages, I used them to improve systems I had already built and to formulate designs for systems I was about to build. Because the results of these efforts were promising, I felt sure I was on the right path. But over time, the power of patterns led me to lose sight of simpler ways to write code. After learning that there were two or three different ways to do a calculation, I'd immediately race towards implementing the Strategy pattern, when, in fact, a simple conditional expression would have been easier and faster to program—a perfectly sufficient solution. On one occasion, my preoccupation with patterns became quite apparent. I was pair-programming, and my partner and I had written a class that implemented Java's TReeModel interface in order to display a graph of Spec objects in a tree widget. Our code worked, but the tree widget was displaying each Spec object by calling its toString() method, which didn't return the Spec information we wanted. We couldn't change Spec's toString() method because other parts of the system relied on its contents. So we reflected on how to proceed. As was my habit, I considered which patterns could help. The Decorator pattern came to mind, and I suggested that we use it to wrap Spec with an object that could override the toString() method. My partner's response to this suggestion surprised me. "Using a Decorator here would be like applying a sledgehammer to the problem when a few light taps with a small hammer would do." His solution was to create a small class called NodeDisplay, whose constructor took a Spec instance and whose one public method, toString(), obtained the correct display information from the Spec instance. NodeDisplay took no time to program because it was less than 10 simple lines of code. My Decorator solution would have involved creating over 50 lines of code, with many repetitive delegation calls to the Spec instance. Experiences like this made me aware that I needed to stop thinking so much about patterns and refocus on writing small, simple, understandable code. I was at a crossroads: I'd worked hard to learn patterns to become a better software designer, but now I needed to relax my reliance on them in order to become truly better. |
