Conscious refactoring has been an integral part of my software writing for over six years now, and I still find myself wondering if I really understand it. Named Patterns too.

Simplicity -- a slightly more recent, but no less important addition -- rounds out what I like to think of as the design triad: A conceptual framework that serves as a stand-in for really explaining what's going through my head when I try to explain my design ideas to others.

Test Driven Development (or Design as I still like to think of it) serves me as a crucible where I use the techniques and ideas expressed in the triad to mold and form the technological raw material available in my current task to express the feature I am trying to build.

There's no real point to this blog entry (Short, and without supporting explanation is my mantra these days) other than to say that as I apply Test Driven Development to a design idea, I find that the interaction of patterns, refactoring and simplicity to be an endlessly fascinating (and pragmatic) way to approach a difficult design challenge. However, to return to my opening sentence, both refactoring and patterns offer the promise of good design, but it takes a lot of practice in using them both before the tempering effects of simplicity can be fully appreciated.

IOW, I think the pitfall of learning both refactoring and patterns is that it can become very easy to take a simple idea and overcomplicate it. In our zeal to introduce a mediator that ensures the view adapts to the model so that our template method is generally applicable to all objects returned from the factory, we are applying tools of considerable power. Power that -- without an eye toward simplicity (i.e. removing duplication, expressing intent), without the discipline of forcing the design to express in response to the tests (i.e. The Three rules of TDD) -- can easily overwhelm our design and turn what would have otherwise been an unstructured ball of spaghetti in a single system/class/method into an overstructured ball of spaghetti in far too many systems/classes/methods.

Anyway, a thought that occurred when reveling in the elegance of a simple design that we explored via a spike last week, and are in the process of expressing test-first this week (and yes the TDD version is both more correct, and simpler than the spike version).