Flylib.com

Books Software

 
 
 

Are the Objects Helping Us?


Are the Objects Helping Us?

We ask this question whenever something seems to be hard to program. If we have to send several messages to an object to accomplish something, maybe that object isn t helping enough. Maybe it needs a method added to it that does more of the job for us. Or perhaps there is another class in there trying to get out. Here s an example from our most recent work, the SingleCharacterSnapshot s Restore() method:

public void Restore(TextModel model) {

String lineToEdit = (String) model.Lines[lineNumber];
String oldLine = lineToEdit.Remove(positionInLine,1);
model.Lines[lineNumber] = oldLine;
model.SelectionStart = selectionStart;
}

This method sends three messages to the model, one message to a string, and no messages to itself. This is a lot of work outside the model. In some of our earlier attempts at Undo, we added methods to the TextModel to help out. We might want to do that here, perhaps this way:

public void Restore(TextModel model) {

model.RemoveCharacterForUndo(lineNumber, positionInLine, selectionStart);
}

supported in TextModel by:

public void RemoveCharacterForUndo(int line, int position, int start) {

Lines[line] = ((string) Lines[line]).Remove(position,1);
SelectionStart = start;
}

Better? Quite possibly. At least the functionality is now where it belongs, instead of over in the Undo, ripping the guts out of the TextModel and jamming them back. We might want to improve the name , but at this moment I don t have a better idea.

We do ask, of course, Are the names helping us? You have seen places where we renamed methods just to make them more expressive.



Did Our Tests and Objects Help Us Enough?

I believe that our tests and objects helped us a lot but perhaps not enough. Im sure that there are places like the one just above, where a clear head and clear eyes would see the possibility of improvement. The improvement above took just a few minutes to do, by the way, and this is often the case. Often we can afford to improve the code, just a little bit, every day. This adds up over time to a much better program.

For this program, I am satisfied with how well the tests and objects help us, but Im not delighted . Im sure it could be better. I hope you have seen places in the code where you know a way to make it better. Im not saying that I left it there for pedagogical purposes; its just that Im not perfect. If you were here pairing with me, we would have done better. Still, the program works and is well- tested . We can be content, if not complacent, about the work we have done.



Eat Your Own Dog Food

We are commonly advised that companies, and software developers, should eat their own dog food. This means that we should have to use the things we provide. I often wish that airline executives were required to sit in the worst seat, on the longest flight, three or four times a month, eating a dry sandwich, and climbing over two large people to get to the restroom. I think it would improve flying tremendously.

With the XML Notepad, we would have benefited from using it more. I did use it a few times, but until very close to the end, it wasnt as capable as my macros in TextPad and it seemed not to make sense to use it. Had I used it, however, I would surely have found issues and changed priorities.

As programmers, we are often unable to eat our own dog foodwe have no use whatsoever for the programs we are called upon to write. Thats another reason why its so important to have an XP customer, a team member who does need the resulting program and who can eat the dog food as soon as we create it.