MultiCast Delegates

[GVN]

Hi All,

I recently worked on delegates. But I have a question regarding
Multicast delegates. The scenario is as follows:

I have a delegate myDelegate with object dlgt, and two methods
myMethod1(), and myMethod2().

Using multicast delegates definition I can write as follows to add the
two methods to my multicast delegate:

dlgt += new myDelegate(myMethod1);
dlgt += new myDelegate(myMethod2);

Can I write the same as follows?

I will create a single cast delegate:

dlgt = new myDelegate(myMethod1);

Inside my myMethod1() I will call myMethod2() method.

What is the difference among the above two cases?

Thanks in advance....

 

[Mattias Sjögren]

What is the difference among the above two cases?

The obvious difference is that in the latter case, you have to know
that myMethod1 should call myMethod2. Delegates are often used for
events where you don't know who else might be interested in being
notified.

A more subtle difference is that in the former case, there's no
guarantee that myMethod1 will get called before myMethod2.


Mattias

 

[Duggi]

Hi
As I see this you by calling method2 from method1,

1. generally delegates can be assigned methods from out side of the
class. as one can not expect how many of the methods would be assigned
to delegate (from client code of delegate) you can never keep on
calling one method from another and another and another.

2. I agree with Mattias point... myclass (that has delegate) will never
know who are interested in getting notified....

The obvious difference is that in the latter case, you have to know
that myMethod1 should call myMethod2. Delegates are often used for
events where you don't know who else might be interested in being
notified.

one can avoid these two points but that will introduce tight-coupling
between the classes of the application.

Thanks
-Srinivas.

 

[GVN]

I thank both Duggi and Srinivas.

I found in both of your postings that:
"Delegates are often used for events where you don't know who else
might be interested in being notified. "

Can you explain me in detail about the above statement? I am still in a
dilemma about the above statement.
My dilemma is that:
The user will declare the skeleton of the delegate. He himself adds
some method(s) to the delegate. He will assign the delegate invocation
to some of the event. Then, why don't we know who else might be
interested in being notified?

 

[Chris]

Think of the Button class. You typically need to tell the call what it
needs to do whenever it is clicked.

Button foo = new Button();
foo.Click += ExecuteMe(Object sender, EventArgs e);

The author of the button class has no idea what you are going to call - but
yet you can call whatever you like without changing any of the original
Button code.

So then the next question is why would you do

Button foo = new Button();
foo.Click += ExecuteMe(Object sender, EventArgs e);
foo.Click += ExecuteMeAlso(Object sender, EventArgs e);

instead of calling ExecuteMeAlso from inside ExecuteMe?

The answer is that it is a design choice. If the only thing that ExecuteMe
and ExecuteMeAlso have in common is that they both need to execute when the
button is clicked, I would keep them seperate. On the other hand, if
ExecuteMeAlso would only work correctly if ExecuteMe had done some type of
action, then I would call ExecuteMeAlso from within ExecuteMe. (or look at
the possibility of refactoring my code)

Hope this helps.

 

[GVN]

Chris,

Thanks a lot for your solution. Really I got a very good understanding
of delegates. Till now I was in ambiguity with my questions, and you
answered them.

Can I have your mail-id so that I can post my questions directly to
you?

Thanks,
GVN.