Mixing enums with event classes in an event aggregator

Question

I attempted to implement my own simple event aggregator recently. I got a lot of inspiration from the event aggregator article on MSDN. There is one thing that I notice about the event aggregator on MSDN is the events are actually classes on their own. This isn't really a bad thing at all. However, I just find it awkward to always create a new empty class for every single little event.

The reason I find it awkward is because of the need to create a class for every single granular event. A mouse click event, for instance, would have double_click, single_click, left_click, right_click, etc. And all of these are going to have a class of its own. It gets messy after a while.

So in my own implementation, I thought I could make it in such a way where the ClickEvent is a class, but all the granular events related to the Click event would then be "types" of the ClickEvent. In this case, the "types" are enum. The usage would look something like this:

//Publisher
eventAggregator.GetEvent<ClickEvent>.Publish(ClickEventType.Double_Click, eventArgs);

//Subscriber
eventAggregator.GetEvent<ClickEvent>.Subscribe(ClickEventType.Double_Click, handlerMethod);

However, I'm not sure if this implementation defeats the whole purpose of having a strongly typed event? Now, it seems like the ClickEvent is merely a container for the different event enum types.

Answer 1

Yes it does (seem like a container that is) - your handler will fire regardless of the click type and there will be some code required in the handler to determine the type of click, which makes things a little messier.

If your issue is mostly the organisation of the files/classes and keeping the code tidy, why not just create the click events as nested classes within a main click class

e.g.

public static class ClickEvents // Prevent instantiation
{
    public class SingleLeft { }
    public class SingleRight { }
    public class DoubleLeft { }
    public class DoubleRight { }
    // Are there any more click events possible?!
}

eventAggregator.GetEvent<ClickEvents.SingleLeft>.Publish();

Aside from that, it's the uniqueness of the type that determines the event signature, and therefore multiple types are required to satisfy this particular implementation

At least the above keeps your handler code clean

void HandleLeftClick()
{
}

vs

void HandleClick(ClickArgs e) 
{
    if(e.ClickType == ClickType.Left)
    {
    }
}

Edit:

Also remember that you can subscribe multiple events to the same handler if you want to handle more than one click type:

eventAggregator.GetEvent<ClickEvents.SingleLeft>.Subscribe(HandlerMethod);
eventAggregator.GetEvent<ClickEvents.SingleRight>.Subscribe(HandlerMethod);

(this would work in the rare situation that the subscriber didn't care which mouse button was clicked)

Answer 2

I think you missed one possibility. You see, you don't have to create a new class for each notification. Instead, you are free to reuse classes but carry some additional state of arbitrary complexity inside.

public class MouseClickNotification {

    public bool IsDoubleClick;
    public MouseButton ClickedButton;

    // any additional stuff

This way it is you who precisely define the granularity of your notification model.