do delegates need to be public methods?

[puzzlecracker]

thanks

 

[Jon Skeet [C# MVP]]

thanks

No. For example:

using System;

public class Test
{
static void Main(string[] args)
{
Action action = Foo;
action();
}

private static void Foo()
{
Console.WriteLine("Foo!");
}
}

 

[Duggi]

thanks

not necessarily... look at the code below...

delegate void myDelegate(int a);

class Csharp
{
private void DelegateMethod(int i)
{
Console.WriteLine("Not exactly");
}

static void Main()
{
Csharp cs = new Csharp();
myDelegate del = new myDelegate(cs.DelegateMethod);
del(10);

Console.ReadLine();
}

}

however, the above is not a practical case. Generally delegates used
for representing some functionality that is expected out of other
objects.. or functionality that would be abstracted to third party. In
which case access to the method is exactly required. (most of the
times through public modifier).

-Cnu

 

[Jon Skeet [C# MVP]]

however, the above is not a practical case. Generally delegates used
for representing some functionality that is expected out of other
objects.. or functionality that would be abstracted to third party. In
which case access to the method is exactly required. (most of the
times through public modifier).

On the contrary, I'd say that most of the time delegates are created
from private methods. Just because a button needs to know what to do
when it's clicked doesn't mean that method has to be public - it can be
private to the class which is subscribing to the event, and that's
usually the case.

Likewise anonymous methods and lambda expressions generate private
methods or methods within private nested classes.

 

[Duggi]

On the contrary, I'd say that most of the time delegates are created
from private methods. Just because a button needs to know what to do
when it's clicked doesn't mean that method has to be public - it can be
private to the class which is subscribing to the event, and that's
usually the case.

Likewise anonymous methods and lambda expressions generate private
methods or methods within private nested classes.

--
Jon Skeet - <[email protected]>
Web site:http://www.pobox.com/~skeet 
Blog:http://www.msmvps.com/jon.skeet
C# in Depth:http://csharpindepth.com

Hi Jon,

Please correct me, if I am wrong...

I think,

On the contrary, I'd say that most of the time delegates are created
from private methods. Just because a button needs to know what to do
when it's clicked doesn't mean that method has to be public - it can
be
private to the class which is subscribing to the event, and that's
usually the case.

This is the case usually with the events (of course a type of
delegate). However the general use case of delegate is to expect the
functionality from some one outside the object, in which case delegate
method becomes public.

May be this is my perception. Please correct me if I am wrong.

-Cnu

 

[Jon Skeet [C# MVP]]

This is the case usually with the events (of course a type of
delegate). However the general use case of delegate is to expect the
functionality from some one outside the object, in which case delegate
method becomes public.

Could you give examples? In LINQ the delegates are almost always
specified as anonymous methods or lambda expressions - methods of
private classes or private methods.

May be this is my perception. Please correct me if I am wrong.

Can you give a common example of where you'd provide a public method?
There are times when that would be useful, of course, but I think it
would be quite rare.

The functionality can be provided to a class separate from the one
creating the delegate, but in my experience the logic within the
delegate is *usually* private to the class creating the delegate.

 

[Duggi]

Could you give examples? In LINQ the delegates are almost always
specified as anonymous methods or lambda expressions - methods of
private classes or private methods.


Can you give a common example of where you'd provide a public method?
There are times when that would be useful, of course, but I think it
would be quite rare.

The functionality can be provided to a class separate from the one
creating the delegate, but in my experience the logic within the
delegate is *usually* private to the class creating the delegate.

--
Jon Skeet - <[email protected]>
Web site:http://www.pobox.com/~skeet 
Blog:http://www.msmvps.com/jon.skeet
C# in Depth:http://csharpindepth.com

Hi Jon,

Please see the example below

delegate Array SortDelegate(int[] a);

/// <summary>
/// Say this class will be developed by other developer
/// </summary>
public class SortClass
{
public Array Sort(int[] arr)
{
// do process for sorting the array which ever order the
business wants.

return arr;
}
}

public class Test
{
public static void Main()
{
int[] arr = { 10, 5, 6, 11, 8, 63 };
SortClass sc = new SortClass();

SortDelegate sd = new SortDelegate(sc.Sort);
Array ar = sd(arr);


Console.ReadLine();

}
}

This is one usecase I thought of on the top of my mind. May be this is
a Bad idea of implementing the logic ...

In my previous my intension was to say the delegates encapsulates the
functionality that can be expected from other classes that will be
developed by other developers in the team...

Correct me if I am worng...

-Cnu

 

[Duggi]

Please see the example below

delegate Array SortDelegate(int[] a);

    /// <summary>
    /// Say this class will be developed by other developer
    /// </summary>
    public class SortClass
    {
        public Array Sort(int[] arr)
        {
            // do process for sorting the array which ever order the
business wants.

            return arr;
        }
    }

    public class Test
    {
        public static void Main()
        {
            int[] arr = { 10, 5, 6, 11, 8, 63 };
            SortClass sc = new SortClass();

            SortDelegate sd = new SortDelegate(sc.Sort);
            Array ar = sd(arr);

            Console.ReadLine();

        }
    }

This is one usecase I thought of on the top of my mind. May be this is
a Bad idea of implementing the logic ...

Well, certainly in the example you give, I think it's flawed.  The code 
you wrote could just as easily have been:

     Array ar = sc.Sort(arr);

There's no obvious reason in the code you posted to go through a delegate 
to call the Sort() method.

Note that more generally, when some "other developer" is writing an  
implementation that you want to call, but your own code does know the name  
of the method, this is typically handled with abstract classes or  
interfaces.  In fact, a delegate could be thought of as a sort of  
one-method interface.

I agree with Jon's observation that delegate methods are most often not  
public.  There's no reason they can't be public, of course, but typically  
if a method is public, then it can already be called by name.  There are  
exceptions, to be sure, but the most common uses of delegates involve  
implementation that is in fact private to a class, and the class exposes  
it only by instantiating a delegate that refers to that implementation.

In fact, one of the most common ways _I_ use a delegate is by creating one  
with an anonymous method.  Anonymous methods are not only private to a  
class, they are private to the method in which they are declared.  They 
are sort of "extra private" if you will.

Named methods will still be with us for delegates for a long time, given  
their importance in the .NET Forms Control class event handler paradigm.  
But so many situations lend themselves nicely to anonymous methods or  
lambda expressions (another way to make an anonymous method) that it seems  
obvious to me that private implementations for a delegate is the norm.

In my previous my intension was to say the delegates encapsulates the
functionality that can be expected from other classes that will be
developed by other developers in the team...

I definitely agree with that.  But I don't agree that it implies that the  
implementation would be public.

Assuming the implementation will be invoked through a delegate provided by  
the "other classes", there's no reason for the implementation to be public  
and good reasons for it _not_ to be.  If the implementation will be  
invoked through a delegate _not_ provided by the "other classes", then it 
begs the question as to why bother using the delegate in the first place?

Pete- Hide quoted text -

- Show quoted text -

Hi Pete,

Thats a good logical analysis.

*** There's no reason they can't be public, of course, but
typically
if a method is public, then it can already be called by name. ****

I do not have an answer. For me it seems logical.

In fact, a delegate could be thought of as a sort of
one-method interface.

I was thinking that this the major usecase of the delegate, which is
wrong.

Assuming the implementation will be invoked through a delegate provided by
the "other classes", there's no reason for the implementation to be public
and good reasons for it _not_ to be. If the implementation will be
invoked through a delegate _not_ provided by the "other classes", then it
begs the question as to why bother using the delegate in the first place?

A valid $ million question.

Thank you very much

-Cnu