I love object-oriented design.  It’s like open source software in general; perfect strangers come up with ideas that can save me time and money and then, out of the goodness of their hearts, go to a fair amount of trouble to pass these ideas on.  I benefit from their efforts every day.

However, you don’t have to go far to find competent, thoughtful, well-intentioned folks who curse and spit when they say ‘design’.  To these folks OOD is anathema; they see it as useless excess that must be avoided at all costs.  

Two things are odd about this situation.  First, while I’m certainly no genius, neither am I a complete idiot.  As a woman of a certain age I’ve been writing code for an alarmingly long time.  I have tons of experience getting applications out the door and my experience is that OOD lowers costs, increases output and keeps code fun.  

Second, when I listen to the anti-design folks explain their points-of-view, I agree with about 99.9% of what they have to say.

You’re an object – Stand up straight and act like one!

Imagine you have this code:

Nothing is more pleasing than beautiful code.  And nothing is more heart-breaking than watching beautiful code get destroyed.

Lately, I’ve been paying particular attention to SOLID Object Oriented Design (OOD) principles and their interaction with TDD.  I’m finding that, while TDD is an essential first step, it just isn’t enough.  If I want my code to survive the rigors of change and be useful for a long time I need to armor it by following SOLID principles.

There’s a delightful symmetry in the feedback loop between TDD and OOD.  TDD in isolation is not guaranteed to produce well designed code, but if you follow the OOD principles while writing the code you’re testing, TDD gets easier and your tests get better.

In case you feel like pushing back already, let me add an early caveat.  If you...