This chapter gives us a short catalog of design patterns. Beck offers an interesting insight, which he credits to Alexander: patterns are a consequence of the fact that we keep using the same tools to solve different problems.
Design in TDD requires a slightly different look at design patterns.
For those keeping score, that's now three things where Kent's concepts have a slightly different take.
He separates his catalog into patterns that appear in test writing, patterns that appear during refactoring, and patterns that can appear in both contexts. Okay... but it's not at all obvious to me that his clusters reflect where these patterns appear in my execution of TDD (why wouldn't value objects be used during refactoring)?
I find the descriptions of the patterns to be little more than sketches; in particular, I find it difficult to understand how some of these patterns differ from the earlier treatments, beyond the fact that he uses Java, rather than Smalltalk or C++ as his primary examples.
Finding Imposters during refactoring is driven by eliminating duplication, just as all refactoring is driven by eliminating duplication.
This I have to dismiss as overstatement, of the same nature as "always start with an automated test". Changing the code to look like we knew what we were doing all along is a perfectly reasonable motivation for refactoring, even if our current design has already eliminated all of the "duplication".
No comments:
Post a Comment