I normally don't use delegates, since I don't do a lot of events programming where they are commonly used. But I was building a class library the other day and found a good use for them.
Here is the scenario: I have a series of methods that allow for merging of records in our main CRM. In order to connect to the CRM, there is a series of setup and tear down calls that have to be made such as connecting, logging in, etc.
So I found myself creating a dozen methods that all looked something like this:
public void mergeAddress(String masterID, String mergeID)
{
try
{
bunch of set up code
meat of the method
bunch of tear down code
}
catch (Exception e)
{
throw new MergeException("Unexpected error in method mergeAddress", e);
}
}
I found myself copying and pasting this chunk of code over and over again, which is always a good sign that some refactoring is required.
My solution was to use a delegate to represent the meat of the method in the middle. Therefore, instead of having a bunch of methods that repeat the same code over and over again, I can now rewrite the method to look something like this:
protected delegate void mergeDelegate(String MasterID, String MergeID);
public void mergeByDelegate(del method, String MasterID, String MergeID)
{
try
{
bunch of set up code
del.invoke();
bunch of tear down code
}
catch (Exception e)
{
throw new MergeException("Unexpected error in method mergeAddress", e);
}
}
Now the method becomes like a prototype - I can keep the set up and tear down in one place and simply sub in the method call in the middle.
(FYI, You could do the same thing by splitting the method into three chunks, moving them into a class and sub-classing the method in the middle, but I think using a simple delegate is easier.)
To implement the prototype now looks something like this:
public void mergeAddress(String MasterID, String MergeID)
{
mergeDelegate del = this.mergeAddress();
mergeByDelegate(del, MasterID, String MergeID);
}
public void mergeAddress(String MasterID, String MergeID)
{
meat of the method
}
All the set up and tear down code is now centralized into one method. The part that changes in the middle can now vary in a variety of ways.
Hope this helps everyone with another way of using delegates...I've always struggled to find a use for them.
Wednesday, July 18, 2007
Subscribe to:
Post Comments (Atom)
Subscribe Now
Blog Archive
-
▼
2007
(99)
-
▼
July
(13)
- Test Driven Development When Writing New Code
- Example of Fat Code
- Agile Tools for .NET Part 2
- Agile Tools for .NET
- Getting to the Finish Line in an Agile Project
- Can You Trust Second Life Charity?
- Creative use of Delegates in .NET
- Low Tech Approaches to Powerpoint Presentations
- LiveEarth not in the top 10?!
- Problems with Live Earth Broadcast
- Creating a Single Sign-On Solution for .NET Part 2
- Creating a Single Sign-On Solution for .NET
- Implementing an Agile Change Control Process
-
▼
July
(13)

2 comments:
:-) All the text above describes the Strategy design pattern, a little bit perverted though..
To my mind it's kind of extra-muddle. Any (?) developer can perceive the code much faster if the clean Strategy pattern is used, especially if a name of that pattern is a part of class-name (postfix e.g.).
I think you're probably right - but I think its probably overkill for what I need at the moment. Having to create a seperate class for each method is a lot of extra burden - creating a delegate is "perverted" in one sense but saves a bit of economy...thanks for the comment!
Post a Comment