Do events really make code decoupled?

Question

So I am trying to use events to decouple code that I have and here is my problem:

class WorldHandler
{
    public void Notify(object sender, EventArgs e)
    {
        if (e is CameraMovedEventArgs)
        {
            // handle event
        }

        if (e is MapLoaded)
        {
            // handle event
        }
    }
}

WorldHandler class listens to different subsystems of my application. Doesn't that mean that WorldHandler is still coupled with other subsystems? Wouldn't it be the same to access those subsystems inside this class directly?

If it's hard to understand what I am asking I will add additional information to my post.

I did research on this problem and I still found this confusing, because different people have very different opinions on how to decouple your code with events.

Answer 1

Yes your code is still coupled, you not only have a direct reference to the class (when you hook up the event handler) but you also have a reference to the assembly containing the class being watched.

You can minimise the coupling by using an interface on the watched class and only accessing it via the items exposed on the interface. Ideally this interface should be in a third "more common" assembly which both the watcher and watchee reference. You can also minimise or eliminate the event coupling by using something like the EventAggregator in Prism.

Coupling in itself is not bad, it simply makes it more difficult (or expensive) to swap out implementations and replace them - without proper decoupling there is considerably more work and more risk of bugs. Your application may not need proper decoupling - it depends on what you intend to do with it.

Answer 2

Using events to react to things happening is decoupling. Decoupling with events isn't bad, I recommend you do it. The purpose of events is that some class says "I have done this" or "I'm about to do this", and other classes can react to the event if desirable. The class that sent the event can't normally know if any other classes reacted to it, unless you tell it of course.

Answer 3

It is said in general that event help you decouple you code, because to the event source all event subscribers are anonymous. In other words, the event source does not need to know the event sink. Whoever does the subscribing to the event (it must not necessarily be the sink) is coupled to the source.

This is by the way true not only for the special case of .NET event, but also for mechanisms like the observer pattern, which is widely used in the Java world for the same purpose as .NET events.

BTW: It is usually not such a good idea to have one method be subscribed to multiple events if the method is not going to invoke the same action for all events. A better way is to have separate handler methods like:

public void NotifyCameraMoved(object sender, EventArgs e)
{
    // handle event
}


public void NotifyMapLoaded(object sender, EventArgs e)
{
    // handle event
}

Answer 4

Decoupling doesn't delete all the dependencies between all components of a program, you shouldn't mix Decoupling/Coupling with Cohesion, a software is good when it has a loose coupling (the coupling is always present).

Still, the events helps code decoupling, the sources that fires the event, and the subscriber to it are totally different and separate objects