<p>Suppose we have:</p>

<pre><code>interface Foo 
{
 bool Func(int x);
}

class Bar: Foo
{
  bool Func(int x)
  {
   return (x&gt;0);
  }  
}

class Baz: Foo
{
  bool Func(int x)
  {
   return (x&lt;0);
  }  
}
</code></pre>

<p>Now we can toss around Bar and Baz as a Foos and call their Func methods.</p>

<p>Delegates simplify this a little bit:</p>

<pre><code>delegate bool Foo(int x);

bool Bar(int x)
{
 return (x&lt;0);
}

bool Baz(int x)
{
 return (x&gt;0);
}
</code></pre>

<p>Now we can toss around Bar and Baz as Foo delegates.</p>

<p>What is the real benefit of delegates, except for getting shorter code?</p>

No, delegates are for method pointers. Then you can make sure that the signature of the method associated w/ the delegate is correct.
Also, then you don't need to know the structure of the class. This way, you can use a method that you have written to pass into a method in another class, and define the functionality you want to have happen.
Take a look at the
List<> class with the Find method
. Now you get to define what determines if something is a match or not, without requiring items contained in the class to implement IListFindable or something similar.