Hey everyone, I have to implement something where I feel the Observer pattern fits. There are multiple objects that observe/listen to certain events. At the moment, they listen to one type of event, but in the future, one class may have to listen to more than one type of event. Which sounds better out of these two:

1. Use a common IObservable interface, but make override NotifyObservers() in each subclass... that way I can call different functions on the observers based on the type of event... like "onEventA()" and "onEventB()"...

2. Create a single Observable class with a dictionary that maps each event type to a list of observers. Observers register with that single Observable object. Then, some class may call FireEvent(EventType et) on the single Observable class, which would grab the appropriate list of observers from the dictionary, and then call onEvent(EventType et) on every observer on that list. That means doing a switch(et) inside onEvent().

Thanks!

As usual, it depends. There's several factors you may want to think about, such as whether you want to pass arguments with an event, if you want your observer framework to be fully typesafe, whether it needs to be threadsafe, etc. If you're using Boost and you're not so bothered about your own implementation of observer, then boost::signals2 is worth a look.

What about having different interfaces for each class being observed? Something like this:

I forgot to mention I'm working with C# (it doesn't support multiple inheritance)... however, under different circumstances, the approach is a good one, so thanks

[quote name='BeerNutts' timestamp='1340741104' post='4953118']
What about having different interfaces for each class being observed? Something like this:

I forgot to mention I'm working with C# (it doesn't support multiple inheritance)... however, under different circumstances, the approach is a good one, so thanks
[/quote]

But you can still implement multiple interfaces. The equivalent to BeerNutts code in C# would be something like


interface IObserverInterface1
{
void HandleThisEvent();
}


interface IObserverInterface2
{
void HandleThatEvent();
}

public class ObservingClass : IObserverInterface1, IObserverInterface2
{
public void HandleThisEvent()
{
// Handle this event
}


public void HandleThatEvent()
{
// Handle that event
}
}



class Event
{
}

class FireEvent : public Event
{
// bla bla bla
}

class IEventObserver
{
public void OnEventTriggered(Event e);
}

class FireEventObserver : public IEventObserver
{
public void OnEventTriggered(Event e)
{
if (e is FireEvent)
{
// do something
}
}
}



class FireEventObserver : public IEventObserver
{
public void OnEventTriggered(Event e)
{
if (e is FireEvent)
{
// do something
}
}
}


Promotes control coupling, no good.
http://en.wikipedia....er_programming)


interface IObserverInterface1
{ void HandleThisEvent(); }
interface IObserverInterface2
{ void HandleThatEvent(); }
public class ObservingClass : IObserverInterface1, IObserverInterface2
{
public void HandleThisEvent()
{
// Handle this event
}
public void HandleThatEvent()
{
// Handle that event
}
}


In my opinion this is over engineering in this particular case, but my be perfect. (You didn't say what your application is exactly) Also this is good if you want to strongly
type different kinds of observers for whatever reason.


Since you are using C#, I would suggest you just use delegates with the dictionary idea if you need multiple observers. Plus if you use events, all of the code for setting and removing observers to/from subjects is generated in the compilation process (+= and -= for events are the things I'm talking about, it's just syntax fluff).