Integrating design patterns “just before they become useful”

I recently commented on a provocative post by Jovan Sranojlovic called “Do Not Use Design Patterns Upfront” He made some thoughtful observations on why design patterns are important to software engineering and how they can a abused in that context as well. However, I disagreed with his basic thesis that design pattern should only be applied in a code refactoring context and not before. Based on his argument, thinking in design patterns upfront, based on the intent and purpose of code in not good, and even harmful. I tweeted my disagreement with a link to JUnit A Cook’s Tour, an example of, what I thought was, thinking in design patterns at the application design stage. The resulting tweet stream follows:

“Do Not Use Design Patterns Upfront” http://tr.im/uI3a – I don’t agree. Beck & Gamma did just that with JUnit http://tr.im/uI3z #asdp
1:09 AM Jul 30th by @chandimac

@chandimac no we didn’t. we explained junit with patterns, but we started with one tiny test and grew the whole thing from there.
6:33 AM Jul 30th by @kentbeck in reply to @chandimac

@kentbeck TX for the clarification. Do you recommend “thinking in patterns” early or should they be added at a later refactoring stage?
6:30 AM Jul 31st by @chandimac in reply to @kentbeck

@chandimac i prefer to put patterns in place just before they become useful. if i can’t see how to do that, then soon after.
6:51 AM Jul 31st by @kentbeck in reply to @chandimac

JUnit A Cook’s Tour explains the design of a system by starting with nothing and applying patterns, one after another, until you have the architecture of the system. As Kent pointed out, the article was written that way, and I had incorrectly assumed that JUnit was developed that way as well.

Design Pattern wisdom in 140 characters

I put patterns in place just before they become useful. If I can’t see how to do that, then soon after.

– Kent Beck

I was quite intrigued by Kent’s reply to my follow up question. It got me thinking about a bunch of issues. What does it mean for a design pattern to be “useful?” How much before is “just before?” What does it mean to “put patterns in place?”

I was so intrigued that I re-read a bunch of stuff on refactoring and design patterns by Beck, Gamma, Kerievsky and Alexander. I try my best to answer some of the questions raised in the remainder of this post – or more appropriately, reconcile some of my cognitive dissonance.

In which ways are design patterns “useful?”

One of the oft suggested reasons for using design patterns is that they “make object-oriented design more flexible, elegant, and ultimately reusable.” That is a direct quote from the GoF Design Patterns book. Although elegance will bring immediate gratification, the fruits of flexibility and re-use are realized in the future, most often during subsequent refactoring. So, in the context of Kent Beck’s preference to apply patterns just before they become useful; is the only useful reward for thinking in patterns upfront, the personal satisfaction of doing something elegantly?

I think we get a little hung up on the flexibility and re-usability that design patterns bring to software development and forget about another aspect that is equally important.

I  found it helpful to go back to Christopher Alexander’s  books on architectural patterns and his argument for design patterns in architecture. Good architecture communicates both form and function. Alexander concentrated on deriving the basic functional attributes of different architectural elements. For example, in A Pattern Language, he said the following about the main entrance.

Place the main entrance of the building at a point where it can be seen immediately from the main avenues of approach and give it a bold, visible shape which stands out in front of the building.

The main entrance can take many forms but its function is common across all main entrances. It has to unambiguously communicate to a person that it is the main entrance. The position of the entrance relative to avenues of approach and its shape compared to other entrances communicates this function. How did Alexander come to this conclusion? By studying main entrances in different buildings designed by different architects and deriving their most salient characteristics.

The architectural pattern for the main entrance does not say anything about how the entrance should be built, what materials to use, dimensions and similar minutia. All it does is communicate its functional attributes at a high level.

Software design patterns communicate intent and function at a high level of abstraction as well. This happens at a much higher conceptual level than lines of code, methods, and individual classes. Patterns communicate in the voice of the collective intelligence of thousands of expert developers who tried, tested, modified and otherwise fine-tuned code in response to a common programming problem until a generic pattern could be identified in the solution.

Just like architectural patterns, software design patterns communicate meaning. They not only tell you that there are relationships between classes, but provides reasons for why those relationships exist. Erich Gamma described this very well in How to Use Design Patterns in Leading-Edge Java Magazine. Although JUnit was developed in a test-driven way, Kent and Erich had highly abstract conversations about the design of JUnit using design patterns. Design patterns provided a “design vocabulary” to expedite development -  Gamma calls this “high-velocity design.”

So, design patterns provide developers with a “design vocabulary” to discuss application design. But what about the individual developer? Is the meaning conveyed by a “design vocabulary” as useful to an individual developer even if he/she doesn’t need to communicate it to someone else?

Is a design vocabulary useful to you?

Design patterns provide a set of concepts describing how and why a set of classes relate to each other, and the order in which they interact with each other. Forget about flexibility, reusability and elegance for a minute; Is the advantage of being able to visualize code at a higher conceptual level reason enough to think in terms of design patterns upfront? Do a simple test, think of a design pattern that you know and understand well. What comes to mind? Do you see code or something else?

ActionScript 3 developers use design patterns every time we sit down to code. How? because AS3 is rife with native implementations of design patterns. For example, the Flash display list implements a Composite Pattern.  Another example is the AS3 Event model, which follows the Chain of Responsibility Pattern by bubbling events up the display hierarchy.

When I think about nested movie clips, I see hierarchical trees with events shooting up and down the hierarchy like lightning bolts. I find this type of visualization incredibly useful to internalize the relationships between objects. Design patterns provide the scaffolding for me to visualize these relationships.

Jesse Freeman wrote a good article recently called 3 Design Patterns Built Into AS3. Can you spot others?

How much before is “just before?”

This is an interesting question as well. If we take the literal meaning of “just before” we will miss the point. We must take “just before” in the full context of Kent’s statement. He says “just before they become useful.” So, the larger question is when do patterns become useful?

Design patterns allow code to be “flexible” allowing  developers to handle change elegantly. Flexible programs are no doubt useful, but are the fruits of flexibility immediately useful? We tend to think  that “change” in code as something that happens way down the road, such as the release of a new version of an application. But does “change” happen on a day-to-day basis? When you consider that most programming projects are not coded in a day, we realize that programming is a continuous exercise in “change.” You may write some code today, but tomorrow you might think that it really “stinks” and modify it or scrap it altogether and start afresh.

This is very well described by Kent Beck himself in a callout in the excellent book, Refactoring: Improving the Design of Existing Code.

Programs have two kinds of value: what they can do for you today and what they can do for you tomorrow….If you can get today’s work done today, but you do it in such a way that you can’t possibly get tomorrow’s work done tomorrow, then you lose.

For example, you may have an inkling that the algorithm you are using today may not be optimal, and decide to integrate a strategy pattern so that it gives you the flexibility to integrate a different algorithm tomorrow without disrupting existing code.

I do realize that Kent’s quote was made in the context of refactoring code. Refactoring to design patterns is also refactoring. So, is putting a pattern in place today to  ease tomorrows work considered “just before it becomes useful?” What do you think?

What does it mean to “put patterns in place?”

The original question that prompted me to write this article was whether design patterns should be put in place only in a refactoring context or whether it is useful to think in terms of design patterns upfront as well. One argument can be that it depends on the development methodology.

For example, if you follow an agile development approach, design emerges from iterative refactoring. In most cases, development relies on feedback provided by tests to drive the design. In this scenario there is not much option but to put design patterns in place during refactoring.

On the other hand, if you follow a more prescriptive approach ( for want of a better term ), there is an emphasis on planning and modeling before coding. In this scenario, there is an opportunity to put patterns in place up front.

One could also argue that it really doesn’t matter because in most projects we use a combination of both development methods.

Ultimately my driving question will probably transform into an argument between the merits of different development methodologies. There is no doubt as to the “usefulness” of design patterns and it may not matter whether you put them into place up front or during refactoring – either way, you will get the benefits.

The Integrating design patterns “just before they become useful” by Chandima Cumaranatunge, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.