Is there a Dependency Injection-like pattern for wiring together Subjects and Observers?

Question

A Subject-Observer relationship isn't a dependency relationship: Observers don't need Subjects in order to exist, and vice versa. Yet the "wiring together" of publishers and subscribers is strongly reminiscent of Dependency Injection.

My shoot-'em-up game makes extensive use of the Observer Pattern. For example:

A controller object spawns a player ship object at the beginning of each round. The controller calls upon a factory to provide the ship. The ship depends, among other things, on a reactor object that can overheat and destroy the ship. The factory injects these dependencies. So far, so good.

Now, the HUD needs to know about the status of the ship, particularly the reactor temperature, but the HUD does not depend on the ship in the DI sense: the HUD persists after the ship is destroyed.

The question is, assuming the controller does not possess a reference to the HUD, how can I get the HUD in touch with the ship? And this is just one teeny, tiny example. I have lots and lots of objects that will need to pass events to one another.

I feel like I could do some of the wiring in the factory, but that feels "wrong", and doesn't help in situations where existing subscriptions need to change.

Anyway, everything I've read about the Observer Pattern ignores this broader issue. Is there an established solution?

Answer 1

You may want to explore using something more general purpose like an "event aggregator" or a central messaging/event disaptching mechanism to do this. That way your HUD can simply subscribe the the event types it cares about, your ships can raise/send those events as necessary, and neither really needs to know about the other. This is one way to decouple things nicely.

Couldn't find a good all-in-on link for you, but here's a discussion of the idea as it relates to a winforms application: http://www.lostechies.com/blogs/derickbailey/archive/2009/12/22/understanding-the-application-controller-through-object-messaging-patterns.aspx

Answer 2

Implementing design patterns typically involves coding the participants yourself: Subject & Observer, in this case. The details of how these objects form their prescribed relationship are really (typically) up to you. Your free to use Spring DI (Java) or any framework that makes sense to you.

But I'm not sure these relationships are good fodder for a typical DI framework. Your Subjects -- as well as your Observers, probably -- will be coming into/leaving existence frequently in the course of the game.

Perhaps you also need some Observers to observe the factories which produce your subjects. That way they can get notified of new Subjects they may want to track, and register themselves as Observers of them.

Answer 3

Castle Windsor has a facility to... er... facilitate this :-) It's called the EventWiring Facility.

See:

• http://hammett.castleproject.org/?p=115
• http://www.castleproject.org/container/facilities/trunk/eventwiring/index.html
• http://mikehadlow.blogspot.com/2010/01/10-advanced-windsor-tricks-6-event.html

If .NET is not your platform you still might want to draw ideas from this.