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?
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