You wouldn't use it like this in practice. Delegates provide a level of
indirection where your instance can be invoked by a class that has no
knowledge of your method beyond it being an instance of a delegate type.

In my experience, delegates come in handy when you are working with
collections. Outside of collections, delegates can be used, as said,
to add a level of indirection. Additionally, multicast delegates allow
multiple methods to be attached at once - most people see this through
events.

Keeping that in mind, delegates should NEVER be used where a good
class heirarchy and/or interfaces and/or polymorphic behavior makes
sense. Like I said, my primary use for delegates have been to work on
a collection, where the delegates play the role of black boxes, the
changing part of the code. If you think about that, delegates provide
a way of working on data where the data may not adhere to a specific
interface. The behavior might change but the data will not.
Polymorphic behavior can work across a heirarchy, but not within the
same class.

So, in summary, delegates find there greatest use, for me, in
1) Events
2) Generic Algorithms and Data Structures
3) The rare need to change a class' behavior at runtime.

Fortunately, most delegates are built-in and you don't have much to
do. If delegates don't make sense, you're trying to hard to use them.
Keep them in your toolset and an opportunity will show itself.

~Travis Parks