Evolutionary Design Today, after having become quite familiar with patterns, the "structures that result from refactoring," I know that understanding good reasons to refactor to or towards a pattern are more valuable than understanding the end result of a pattern or the nuances of implementing that end result. If you'd like to become a better software designer, studying the evolution of great software designs will be more valuable than studying the great designs themselves. For it is in the evolution that the real wisdom lies. The structures that result from the evolution can help you, but without knowing why they were evolved into a design, you're more likely to misapply them or over-engineer with them on your next project. To date, our software design literature has focused more on teaching great solutions than on teaching evolutions to great solutions. We need to change that. As the great poet Goethe said, "That which thy fathers have bequeathed to thee, earn it anew if thou wouldst possess it." The refactoring literature is helping us reacquire a better understanding of good design solutions by revealing sensible evolutions to those solutions. If you want to get the most out of patterns, you must do the same thing: See patterns in the context of refactoring, not just as reusable elements that exist apart from refactoring. This is my primary reason for producing a catalog of pattern-directed refactorings. By learning to evolve your designs, you can become a better software designer and reduce the amount of work you over or under-engineer. TDD and continuous refactoring are the key practices of evolutionary design. Instill pattern-directed refactorings into your knowledge of how to refactor and you'll find yourself even better equipped to evolve great designs. | 
