views:

155

answers:

3

I understand delegates as a shortcut for defining a class with one method but what is the meaning of bar2 below? It compiles. But I can't see what an inner class would do here. I know I'm missing something so that's why I'm asking (this is not homework, I'm at work-work right now).

namespace ns2 { public delegate void bar();}
public class foo
{
    private ns2.bar _callback;
    public foo(ns2.bar callback) { _callback = callback; }
    public void baz() { _callback(); }
    public delegate void bar2();
}

Thanks!

+6  A: 

Delegates are not shortcuts for defining a class with one method. They in fact have at a minimum 6 methods (Invoke, BeginInvoke, EndInvoke, GetHashCode, Equals, ToString).

One reason for the pattern of putting delegates inside a type is to avoid global namespace pollution. The delegate bar2 is only accessible through a qualified reference from foo. This can be valuable if bar2 is a name which has multiple valid meannings and putting it within foo provides necessary context.

JaredPar
+1, didn't like the characterization of delegates being shortcuts for defining a class with one method either. Must be a legacy of anonymous classes from Java.
Kirk Woll
It's more reasonable to think of a delegate type as being like an *interface* with one method, IMO... and then extra ways of calling that method for asynchronous operations. To me that gets the *feeling* of delegates right. Out of interest, is `BeginInvoke` guaranteed but `EndInvoke` not?
Jon Skeet
@Jon, `EndInvoke` is guaranteed as well (updated my answer).
JaredPar
http://msdn.microsoft.com/en-us/magazine/cc301810.aspx puts delegates in terms of IL which is how i arrived at my way of thinking
Gabriel
+5  A: 

It's just declaring a nested type, that's all. As it's public, there's pretty much no difference between that being declared inside the type and being declared outside.

Other classes will have to refer to it via the name of the containing type (unless they have a using directive specifically for it):

public class OtherClass
{
    private void DoSomething()
    {
        foo.bar2 action = delegate { ... };
        foo f = new foo(action);
        ...
    }
}

Usually when I write a nested type, it's private - it's just a helper class for the containing class; an implementation detail. That doesn't have to be the case, of course, but it should at least be true that the nested type is meaningless unless you're in some way using the outer class. For example, it could be a builder for the outer class, or an enum used in some parameters for a method call within the outer class.

(By the way, it's useful when writing sample code like this to follow .NET naming conventions even for meta-syntactic names like Foo and Bar. It makes the difference between variables and types clearer, for example.)

Jon Skeet
Thanks for the answer and the tips.
Gabriel
+5  A: 

To add to Jon and Jared's answers, I note that the only time you'd usually define a delegate inside a class is if the delegate were a private implementation detail of the class. It is rare and bizarre to have a public delegate definition inside a class.

For example, consider my favourite pattern: an abstract base class that can only be extended by private nested classes that are manufactured with factories:

public abstract class Animal
{
    private Animal() { } // prevents subclassing from outside!
    private sealed class Giraffe : Animal { }
    private sealed class Leopard : Animal { }
    public static Animal GetGiraffe( ) { return new Giraffe(); }
    public static Animal GetLeopard( ) { return new Leopard(); }

Suppose an implementation detail of Animal was that you needed to have a delegate from Giraffe to Leopard:

    private delegate Leopard D(Giraffe g);

This cannot be a public delegate class because it refers to private types!

Nowadays of course you wouldn't even do this. You'd use Func<Giraffe, Leopard> and you're done.

Therefore, the nested delegate type is pretty much there for completeness and backwards compatibility these days; normally you wouldn't use it.

Eric Lippert