We Need an Object

Look at that code up there for SetInput. Either we have a two-pass algorithm or we have a complex setup to call a function that will be hard to write and that might still have a two-pass algorithm in it. Maybe I wasn t so wrong after all. The two-pass thing isn t as much a concern about speed, perhaps, as about our ability to express ourselves : we can t say what we want when we do it this way.

So we imagined some new object that holds input. We called it an InputCommand, and our proposed code looks like this:

 private void SetInput(StringReader reader) { 
 InputCommand input = InputCommand(reader); 
 model.Lines = input.CleanLines(); 
 model.SelectionStart = input.SelectionStart(); 

If we can do something like that, it will be quite clean! So we imagine an object that will take the input from the reader that holds the whole script. It will know how to produce the clean lines (the ones without the vertical bar), and it will know how to say where the SelectionStart (cursor location) is. We think we like this. And we re pretty sure it will be easy to write. Tomorrow we re going to start on it.

Lesson: Lessons Relearned Today

If You Can t Test It, It s Wrong

When we realized we couldn t readily test this code, we should have stopped coding. The lack of testability was telling us, long before anything else did, that there was at least one missing object.

Procedural Code Is a Very Bad Smell

When you find yourself writing procedural methods and utility methods and railing at how the objects aren t helping you, this, too, is telling you that there s a missing object.

Too Long Between Green Bars

After we made our one new unit test work, we went for a long time without a new test or a new green bar ”basically, all the time after lunch . This is at least a sign that you re stuck, and it should be used to trigger a rewind and a start in some new direction. Or even to start over in the same direction.