Reputation: 760
In my scenario, I have a class that will do some work for me every now and then and occasionally will react with some action to it. What the action actually is will be provided from the outside. I think it's important to mention, that there will be only one instance from the outside telling this class what has to be done.
I've implemented something like this:
public class DelegatePublisher
{
private Action<byte[], int, int> onCompleted;
public DelegatePublisher(Action<byte[], int, int> onCompleted)
{
this.onCompleted = onCompleted;
}
public void Invoke(byte[] buffer, int index, int count)
{
onCompleted.Invoke(buffer, index, count);
}
}
This can be used later as simple as:
public class Example
{
public void Test()
{
var byAction = new DelegatePublisher(onDelegate);
}
private void onDelegate(byte[] buffer, int index, int count)
{
// do stuff
}
}
Once Invoke
will be called the action will be called. (I left out all that null
checking on purpose for the sake of this minimal example)
This works as expected and I am happy with that solution. However, people keep telling me that I should use Events
. I told them that I just need a single Action
to be invoked, and the code does it perfectly fine. After a long discussion, the code now looks like this:
public class EventPublisher
{
public EventHandler<EventPublisherEventArgs> OnCompleted;
public void Invoke(byte[] buffer, int index, int count)
{
var handler = OnCompleted;
if (handler != null)
{
handler(this, new EventPublisherEventArgs(buffer, index, count));
}
}
}
And of course the EventArgs
:
public class EventPublisherEventArgs : EventArgs
{
public byte[] Buffer
{
get;
private set;
}
public int Index
{
get;
private set;
}
public int Count
{
get;
private set;
}
public EventPublisherEventArgs(byte[] buffer, int index, int count)
{
Buffer = buffer;
Index = index;
Count = count;
}
}
My ... well, "calling" code now looks like this:
public class Example
{
public void Test()
{
var byEvent = new EventPublisher();
byEvent.OnCompleted += onEvent;
}
private void onEvent(object sender, EventPublisherEventArgs e)
{
// do stuff
}
}
Is there actually any benefit in doing it as an Event
? Or the other way around: Is there something wrong with the way using an Action
?
All I can tell by using Events
is that I need more code, have an extra layer of abstraction, could potentially connect multiple (not needed) callbacks and need an extra class just to hold three parameters. The only good thing I see is that I am following a common pattern. However, I have seen lots of code with passing an action as parameter, even in the BCL, which could probably be solved with events as well.
Upvotes: 1
Views: 75
Reputation: 149538
Is there actually any benefit in doing it as an Event?
Although highly opinionated, ill try and shed my point of view.
I don't see any straight forward benefit. It usually depends on what you need. Events are merely wrappers around delegates, they add another level of abstraction (as you said).
Must you use them? no, i see nothing wrong with your working code example. Don't conform to using certain patterns because "people think they're better". Follow them because you've looked and see an obvious benefit in using them. In this particular case, i don't see any added value.
Upvotes: 1