I Built His Cage

As I imagine you’re noticing by now, my Atwood-recommended posting schedule is roughly every Wednesday and Saturday. That is twice as much as my initial goal.

Let’s dish about that TDD animal. I would like to argue that this acronym should always stand for Test-Driven Development, and never Test-Driven Design.

Why am I even making a fuss over seemingly interchangeable terms? First, I don’t think development and design are interchangeable. Second, depending on your goal at the time, the choice of one versus the other can have an impact on productivity.

I am speaking from experience. My recent attempt at re-implementing core parts of The Project spawned spin-offs that have been featured on this blog:

• Dynamic State Pattern
• Method Regulator Pattern
• DataGrid Pagination in Windows Forms

This isn’t counting three other side-trips into the worlds of homemade IoC containers, design and placement of factory objects, and gluing the UI and Application Layers together without using events.

All of these detours occurred while I was practicing Test-Driven Design. At every step, I made sure I had working code of some kind, and I tried writing the test first. And I think this is the problem.

My initial goal of this re-implementation was to fix some of the sins I committed during the project, mostly sins in my Domain layer. However, I had to have working code at each step, and the more I ventured onto each side street (all of which, you’ll see, are not related to the domain), the more distracted I became and the more time I spent on the interesting technical distractions and not on the real problem at hand.

What I really wanted to do was gain some clarity on the mistakes I made during design. TDD was not necessarily getting in the way of me doing so, but was proving a big enough distraction to pull me away from what I really set out to do.

I find that for design-to-code activities, I am much better suited if I am not in front of a compiler, but rather a plain old text editor. Consider this a whiteboard for the coder. This way, no compiler is going to throw warnings and errors at me that I am aware of and don’t care about right now.

(I love whiteboards)

Just in the past couple of days, I used this technique to clarify how to deal with modeling an object, like Equipment, that doesn’t have complicated logic behind it. All you really want to do with it is record some sort of description of the Equipment, like its color, serial number, model, make, etc.

I haven’t had a chance to seriously address this question since I started the redo of The Project because of all of the detours. So I shut down the IDE and opened up Crimson Editor.

At this point, I refuse to capitulate to using getters and setters. Additionally, technically speaking, this is not a coding challenge. I was really on a mission to apply Tell, Don’t Ask and to produce pleasant, readable code.

A few sessions in front of my editor and I produced a wide variety of possibilities that I never could get to in front of Visual Studio:

equipToAdd.setSN(“19836AG19″);
_________________________________
equipToAdd.update(“S/N”, “19836AG19″);
_________________________________
equipToAdd.describe(new EquipmentDescription(…));
_________________________________
equipToAdd.describe(new HashMap(…));
_________________________________
phone.applyDescription(new EquipmentDescription(…));
_________________________________
equipDesc.describeAttribute(“S/N”, “19836AG19″);
_________________________________
equipDesc.describe(“S/N”, “19836AG19″);
_________________________________
new Phone(new EquipmentDescription(…));
_________________________________
new Phone(“Black”, “19836AG19″, “Avaya”, …);
_________________________________
equipDesc.write(“S/N”, “19836AG19″);
_________________________________
equipDesc.update(“S/N”, “19836AG19″);
_________________________________
equipDesc.writeSN(“19836AG19″);
_________________________________
equipDesc.updateSN(“19836AG19″);
_________________________________
equipToAdd.describeYourself(“S/N”, “19836AG19″);
_________________________________
equipToAdd.describeSelfWith(“S/N”, “19836AG19″);
_________________________________
bob.describe(phone);
…
public class User
{
    public EquipmentDescription describe(Phone p)
    {
        EquipmentDescription descriptionOfPhone;

desc.acceptAttribute(“S/N”, “19836AG19″);
Equipment equipToAdd = new Equipment(desc);
_________________________________

As you can see, this is a raw look at myself playing with method name, placement, and signature to find what best fits reality. I was able to focus solely on this because I was using the developer’s whiteboard: the text editor.

Ultimately, I decided, for now, on either of the last two choices shown. I arrived at it by imagining what people would do to describe equipment if there were no computers. Basically, I would grab a piece of paper and write down a description of the equipment: “Color: Black. Type: Phone. Serial Number: 19836AG19. …”

What is intrinsic about this description is that the attributes are valid. The equipment I’m describing, a phone, has color, type, and serial number attributes. If I had written “Favorite Weapon: Plasma Gun”, this would make no sense. The description, by its very nature, has to “accept” the attribute as valid, and it does so by virtue of its essence.

(“Piece of paper, accept the description that this guy is a criminal”)

Hence, I decide to tell the description to accept “Color: Black”, “Type: Phone”, and “Serial Number: 19836AG19″.

At first, I wasn’t even going to have an Equipment object, because I wasn’t thinking about any other logic that would be needed. It makes no sense to tell Equipment to accept an attribute; that is the job of the description. But as I moved on considering the requirement that a piece of Equipment is stored in one and only one Room, it became clear to me that it makes no sense to store Equipment Descriptions in Rooms.

Besides, the location in which Equipment is stored is not part of its Description. Neither is its system-wide ID, last modification time of its Description, and who changed it.

I think you get the picture. I’m going to stop because I could go on and on about this. The point is this wasn’t possible in front of an IDE. That is the wrong place to do this sort of design.

An actual whiteboard with markers and an eraser drawing UML is also the wrong place for this sort of design. UML is nice and great for important tasks, but it is too high-level if you want to get a feel for what the code should look like, and more importantly, how the objects should interact on a code level.

Reserve Test-Driven Development for when you are actually ready to take a design from concept to reality. Simulate Test-Driven Design with the coder’s whiteboard: your text editor of choice.