TDD is the first leg of emergent design or what could be called Agile Design. Design patterns are the second. They’re often described as “solutions to recurring problems in a context.” In this way they can be thought of as recipes that have been learned. But patterns open the door to much more; they are examples of ways to think. Patterns hide varying behavior, structure or which objects to use.
This is not just variation at a particular time. They can also be used when variations occur over time. That is, you might start thinking you need something at the start only to change it later. Patterns can hide this change.
Design patterns work with TDD by providing us with insights on how to implement variations into our code while enabling our tests to be decoupled from each other. The intent is to write decoupled tests; that is, when one behavior changes only one test needs to be change. This is, of course, an idealized goal.
It is worth noting that the first mantra of patterns is design to the object’s behavior. Just like we do in TDD.
My next blog will discuss the third leg of emergent design: Acceptance Test-Driven Development.
This is Al Shalloway. Visit us at www.netobjectives.com. Write me at firstname.lastname@example.org.