Converting XMLNotepad to Use Delegates

Kevin s example actually showed how to duplicate my whole Perform thing using delegates, but a simpler and equally effective approach exists. (As we ll see, equally effective is used advisedly.) The XMLNotepad code looked like this:

 void MenuInsertSection(object obj, EventArgs ea) { 
 model.SetLines(textbox.Lines); 
 model.SelectionStart = textbox.SelectionStart; 
 model.Perform("InsertSectionTags"); 
 PutText(textbox, model.LinesArray(), model.SelectionStart); 
 } 

Going to a delegate approach, we add a delegate definition and use it this way:

 private delegate void MenuAction(); 
 void MenuInsertSection(object obj, EventArgs ea) { 
 model.SetLines(textbox.Lines); 
 model.SelectionStart = textbox.SelectionStart; 
 MenuAction action = new MenuAction(model.InsertSectionTags); 
 action(); 
 PutText(textbox, model.LinesArray(), model.SelectionStart); 
 } 

Now, of course, in this mode, the whole thing makes no sense. We could imagine some future day when there was a general MenuHandler method where all the menu clicks came in and we selected which function to delegate with some if or switch statements. So the ifs would choose which method to delegate to, and then action() would call it. The thing is, this is still not a very good idea. Instead of writing code that says

 if(something) action = model.InsertSomething; 
 else if(other) action = model.InsertOther; 
 action(); 

why not just write this?

 if(something) action = model.InsertSomething(); 
 else if(other) action = model.InsertOther(); 

This should make it clear that the Perform I originally wrote, and the delegate approach just used, is a waste of time from a product viewpoint. So I m going to take it out, right now. The new code (old code) looks like this:

 void MenuInsertSection(object obj, EventArgs ea) { 
 model.SetLines(textbox.Lines); 
 model.SelectionStart = textbox.SelectionStart; 
 model.InsertSectionTags(); 
 PutText(textbox, model.LinesArray(), model.SelectionStart); 
 } 

Tests run, GUI runs, all s right with the world.

Lesson: My Point, and I Do Have One

I ve spent at least one precious programming day messing with Perform, reflection, and delegates. Now I ve learned a lot about those things. I predict that in the entire rest of this book, I ll never once have a use for the Perform approach. I suspect that you might see some use of delegates, but it s likely it won t show up for a while. I do feel better knowing those things, and that will make me a little more comfortable writing programs and a little more confident that I can clean up any messes I might make.

But remember: all this was done on speculation. I was concerned that I was going to get duplication when I added more features, and I was concerned that I wouldn t be able to get rid of it. What I wasn t concerned about was adding more features. One precious programming day has gone by. We have a better programmer at the end of it, and that s a good thing, but we don t have a better program and we don t have a happier customer.

Those, I believe, are both bad things. The lesson should be: we should learn as much as we can, all the time. And we should be careful to keep our learning focused on safely delivering the customer the features he needs.

(My technical editors also note that while delegates can be very useful for communicating between separately developed modules, it is almost always clearer to have your objects communicating by direct method calls rather than by delegates, where that s possible. We have learned that here for ourselves .)

Later today, I m planning to meet with Chet and do some pairing . I m sure he ll put his customer hat on and be disappointed at my progress. I hope he s nice enough to say that he s glad I m learning, or I ll feel really bad. And it will be his fault. ^[1]

 

^[1] Remember, it s always Chet s fault.