Static Events Notifier

A few days ago a teammate asked to me to help him with a little some-some. This some-some was an event delegation problem (some-some sounds better) that she wanted to implement and wasn’t really sure how. The scenario is quite simple, we have a few classes and one of the classes is a little “deep” (deep object graph), meaning:

object of type A 
object of type B 
object of type C 
   inner member of type class D 
     inner member of type class E
      inner member of type class F – known as f1

Now, the value f1 can change, and while it does so, we need to notify the rest of the instances (a1,b1,c1,d1,e1) of that change and provide them some extra details about the change itself. One solution is to add an event to all the classes, register from each one to the inner member event and then f1 can trigger the change to E which will trigger the event to D and then to C->B->A. In short – delegate the call all the way up and around. It seems like a hard job to me – too many places to change, too many events to declare which are not really necessary. I came up with a static Events Notifier solution. Think of it as a repository for registering and triggering events. Here it goes:

public static class EventsNotifier
   public static event EventHandler<Status> StatusChanged = delegate {};

   public static TriggerChangeStatus(object sender, Status s)
      StatusChanged(sender, s);

Now each class, in its constructor, can register to EventsNotifier.ChangeStatus event and my f1 can call EventsNotifier.TriggerChangeStatus(this, new Status(…)); which will notify the rest of the objects. I know, it’s not a perfect solution, but It has its pros. What would you do ?


Oren Ellenbogen


3 thoughts on “Static Events Notifier

  1. I think you’re better off with delegating a call up the object graph and having each object register for the change event (no need to declare any more events…).

    Static methods are messy, they increase coupling and reduce maintainability. You want your objects "talking" to their collaborators (members) only and making as little assumptions as possible on the rest of the system. Some good design patterns addressing the issue you brought up are: Visitor, Chain of Responsability and Observer.

Comments are closed.