A Twist on the Observer Pattern

The observer pattern is well established and used. The typical scenario is to register to an class and then allow your Notify method to be called. This often involves keeping an internal list of observers and then iterating them to notify that something has changed. I had a situation recently that warranted a lighter weight approach that allows a many-to-many observation (multiple listeners, multiple objects to observe).

I was working with the Composite WPF/PRISM framework and had an interesting situation. One of my regions is implemented as a TabControl, so modules that register with the RegionManager inject their views into the tabs. This is a very powerful model because now I can add as many modules/views as I like and not worry about the implementation details of wiring up the tab control. I created a view interface IViewable to implement with my controls that exposes the name of the view along with a boolean indicating whether the view should be enabled (this allows me to restrict going to certain tabs if they depend on data from another tab).

The issue was figuring out the best way to handle the tab focused event. By default, the views are wired up and ready to go when you click the tab. I tried searching for a solution to allowing my view to know when it was “active” but didn’t find much that was satisfactory. It could be I’m completely off on my approach because there is some pattern already existing, but I decided to go with something very lightweight … even lighter than the observer pattern. I don’t want to know the details of what the other views or modules are, I just want to know when I’m getting focus and that is controlled by my parent container (I also shouldn’t know that my parent container is a TabControl – it could be any ItemsControl for that matter).

The pattern was quite simple, really. First, I created an interface:

public interface IObservableHelper 
{
   void Notify(object obj); 
   event EventHandler<EventArgs> Notified; 
}

The implementation was easy too:

public class ObservableHelper : IObservableHelper
{
   public void Notify(object obj) 
   {
      if (Notified != null) { Notified(obj, EventArgs.Empty); }
   }

   public event EventHandler<EventArgs> Notified;
}

See, very easy. I don’t have to keep track of the objects observing because objects who want to know about this event simply register to the event. In my boot strapper class I make sure there is exactly one instance of the helper:

...
Container.RegisterInstance<IObservableHelper>(new ObservableHelper()); 
...

With the dependency injection, the helper can be injected simply by asking for it in the constructor. That means in my view, I can do this:

public MyView(IObservableHelper helper)
{
   helper.Notified += (obj,args) =>
   {
      if (obj == this) { DoSomething(); }
      else if (obj is ISomeInterface) { DoSomethingElse((ISomeInterface)obj); }
   }; 
}

// observe "me" 
public void DoSomething()
{
} 

// observe "ISomeInterface" 
public void DoSomethingElse(ISomeInterface someInterface)
{
}

I’ve just registered to, eh, observe “myself.” That’s OK … as a view, what I really want to know is when I am activated. So in the shell, I simply tap into the selection changed event for the Tab Control. That will resolve IObservableHelper then call notify with the element that was selected. Notified will fire, I’ll see its “me” and then call DoSomething. Very lightweight and decoupled … and if there are other objects participating, I can interact with them as well!

codeproject