After reading the article- When to Use Delegates Instead of Interfaces (C# Progr
ID: 642235 • Letter: A
Question
After reading the article- When to Use Delegates Instead of Interfaces (C# Programming Guide), I need some help understanding the below given points, which I found to be not so clear (for me). Any examples or detailed explanations available for these?
Use a delegate when:
An eventing design pattern is used.
It is desirable to encapsulate a static method.
Easy composition is desired.
A class may need more than one implementation of the method.
Use an interface when:
There are a group of related methods that may be called.
A class only needs one implementation of the method.
My Questions are,
What do they mean by an eventing design pattern?
How the composition turns out to be easy if a delegate is used?
if there is a group of related methods that may be called,then use interface-What benefit it has?
if a class only needs one implementation of the method, use interface-how is it justified in terms of benefits?
Explanation / Answer
What do they mean by an eventing design pattern?
They most likely refer to an implementation of the observer pattern which is a core language construct in C#, exposed as 'events'. Listening to events is possible by hooking a delegate to them. As Yam Marcovic pointed out, EventHandler is the conventional base delegate type for events, but any delegate type can be used.
How the composition turns out to be easy if a delegate is used?
This probably just refers to the flexibility delegates offer. You can easily 'compose' certain behavior. With the help of lambdas, the syntax to do this is also very concise. Consider the following example.
class Bunny
{
Func<bool> _canHop;
public Bunny( Func<bool> canHop )
{
_canHop = canHop;
}
public void Hop()
{
if ( _canHop() ) Console.WriteLine( "Hop!" );
}
}
Bunny captiveBunny = new Bunny( () => IsBunnyReleased );
Bunny lazyBunny = new Bunny( () => !IsLazyDay );
Bunny captiveLazyBunny = new Bunny( () => IsBunnyReleased && !IsLazyDay );
Doing something similar with interfaces would require you to either use the strategy pattern or using an (abstract) base Bunny class from which you extend more specific bunnies.
if there is a group of related methods that may be called, then use interface-What benefit it has?
Again, I'll use bunnies to demonstrate how it would be easier.
interface IAnimal
{
void Jump();
void Eat();
void Poo();
}
class Bunny : IAnimal { ... }
class Chick : IAnimal { ... }
// Using the interface.
IAnimal bunny = new Bunny();
bunny.Jump(); bunny.Eat(); bunny.Poo();
IAnimal chick = new Chick();
chick.Jump(); chick.Eat(); chick.Poo();
// Without the interface.
Action bunnyJump = () => bunny.Jump();
Action bunnyEat = () => bunny.Eat();
Action bunnyPoo = () => bunny.Poo();
bunnyJump(); bunnyEat(); bunnyPoo();
Action chickJump = () => chick.Jump();
Action chickEat = () => chick.Eat();
...
if a class only needs one implementation of the method, use interface-how is it justified in terms of benefits?
For this, consider the first example with the bunny again. If only one implementation is ever needed - no custom composition is ever required -, you can expose this behavior as an interface. You will never have to construct the lambdas, you can just use the interface.
Conclusion
Delegates offer a lot more flexibility, while interfaces help you establish strong contracts. Therefore I find the last point mentioned, "A class may need more than one implementation of the method.", by far the most relevant one.
An additional reason when to use delegates is when you want to expose only part of a class which you can't adjust the source file from.
As an example of such a scenario (maximum flexibility, no need to modify sources), consider this implementation of the binary search algorithm for any possible collection by just passing two delegates.