Why use Delegates?

[samadams_2006]

Hello,

I'm trying to figure out why delegates are such a great thing. For
example, I came across the following line of code:

"This ability to refer to a method as a parameter makes delegates
ideal for defining callback methods. For example, a sort algorithm
could be passed a reference to the method that compares two objects.
Separating the comparison code allows the algorithm to be written in a
more general way."

Can someone explain this to me?

Thanks
Sam

[sloan]

The quote you provide, look here:
http://www.dofactory.com/Patterns/PatternStrategy.aspx

Event and delegates are kinda DotNet's "built in" observer pattern.
Check this:
http://www.dofactory.com/Patterns/PatternObserver.aspx

This would be the most obvious to me.

When something "happens"....you can register and unregister things which are
interested in it.

Let's say you write software for your state school system.

When a new student is registered...today, maybe the school and the county
and the state are interested.
However, tomorrow, the cdc might be interested in it.
You code it up to "raise events" when a student is added, and thus you can
add/remove people who are interested in it.

Its a way to build maintainable code at its heart.

I would recommend the "Head First Design Pattern" book if you're serious
about software development for the long haul.


<sa***********@yahoo.cawrote in message
news:bf**********************************@k37g2000 hsf.googlegroups.com...

Hello,

I'm trying to figure out why delegates are such a great thing. For
example, I came across the following line of code:

"This ability to refer to a method as a parameter makes delegates
ideal for defining callback methods. For example, a sort algorithm
could be passed a reference to the method that compares two objects.
Separating the comparison code allows the algorithm to be written in a
more general way."

Can someone explain this to me?

Thanks
Sam

[samadams_2006]

Maybe I'm not seeing it... Let's look at the example in the first
link provided above. Here it is:

class MainApp
{
static void Main()
{
// Two contexts following different strategies
SortedList studentRecords = new SortedList();

studentRecords.Add("Samual");
studentRecords.Add("Jimmy");
studentRecords.Add("Sandra");
studentRecords.Add("Vivek");
studentRecords.Add("Anna");

studentRecords.SetSortStrategy(new QuickSort());
studentRecords.Sort();

studentRecords.SetSortStrategy(new ShellSort());
studentRecords.Sort();

studentRecords.SetSortStrategy(new MergeSort());
studentRecords.Sort();

// Wait for user
Console.Read();
}
}

Why couldn't you just define 3 new methods, as shown below, and get
rid of the "SetSortStrategy":

studentRecords.QuickSort();
studentRecords.Sort();

studentRecords.ShellSort();
studentRecords.Sort();

studentRecords.MergeSort();
studentRecords.Sort();

If you wanted to add another algorithm, such as: BubbleSort(), you
would still need to add this algorithms to the code, and compile it.
I've heard that one of the features of delegates is that it is is more
"dynamic"....doesn't seem to dynamic to me?

Thanks

[Jeff Louie]

Sam... As you can gleam from the responses here: delegates, interfaces
and
inheritance can all be used to provide runtime variation in behavior.
What we are
really talking about here is different idioms used to achieve runtime
polymorphism.

Runtime polymorphism involves programming to a type, such that the
implementation details can be different and are discoverable at runtime.
When
programming to a type, the caller does not know the class of the object,
only
that the object implements the type of interest. Polymorphic behavior
can be
achieved using using interfaces, abstract classes/subclassing or
delegates/events. Each approach has advantages and disadvantages.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[raylopez99]

On Oct 23, 3:40*pm, [e-mail] wrote:

Hello,

I'm trying to figure out why delegates are such a great thing. *For
example, I came across the following line of code:

"This ability to refer to a method as a parameter makes delegates
ideal for defining callback methods. For example, a sort algorithm
could be passed a reference to the method that compares two objects.
Separating the comparison code allows the algorithm to be written in a
more general way."

Can someone explain this to me?

Thanks
Sam

I was like you about three months ago.

My newbie advice: get the book by Albahari C#3.0 in a nutshell. or,
just study delegates until your eyeballs drop out. Then study events
(a form of delegate). After about the tenth example it finally dawns
on you.

The way I like to think of it (and others on this board disagree):
delegates are a kind of global "GOTO" statement, where a function/
method can fire a delegate GOTO and have several portions of code that
are "registered" to listen to the delegate execute code the minute the
function/method fires, even when the function/method is unaware of
these registered portions of code. So you can have multiple "GOTO"s
execute simultaneously.

If that sounds complicated, it is. Believe me, delegates will make
your head hurt. But there's no other way to learn them. Nothing
anybody says in this thread--no matter how right--even me--will make
you understand delegates. You just have to keep trying until you
finally 'get it'.

Good luck.

RL