does TDD lead to functional decomposition?

Hi all,

I've been thinking lately about how you could go wrong with TDD and
emergent design (as I am presenting something on emergent design at the
local XP user group)

The main thing I can think of is that you get led down a functional
decomposition route.  Ie, you tend to think... "the software has got to
do this, then this, then this".  When it comes to refactoring removing
duplication is relatively easy to get rid of at the level of copy paste
duplication and methods of a very similar form, but finding abstractions
is harder.  If you havent refactored code with the DIP in mind your
likely to miss some duplication as well. Finding something that isnt
cohesive is something that you have to actively look for. So what you
then end up with Test Driven Functionality.  Thing is, it should be
reasonably nice, it should be readable, and it should be relatively
decoupled.  However, the design is not the best,  tests maybe way too
involved / complex, adding functionality gets harder, design is a bit
confusing, not entirely sure where to start tracking down bugs.

....

However on the flipside, I figure if you're an OO kind of person, then
you tend to have a running conversation with your partner about the
objects involved and their responsibilities and how they are going to
accomplish your what you need to do. In fact, in your mind you tend to
have a whole bunch of OO principles / patterns / experience which you
are trying to apply where needed to the problem at hand.  Refactoring
allows you to constantly revisit the design and apply principles that
weren't seen at the testing stage....


Key thing Im trying to extract out of this is that without a good
knowledge of OO principles / patterns / etc it gets hard for good OO
designs to emerge.

Comments? Thoughts?

Regards,

Keith Nicholas