主体 - 观察者关系不是依赖关系：观察者不需要主体以便存在，反之亦然。然而，出版商和订阅者的“联系在一起”强烈让人联想到依赖注入。
我的射击游戏大量使用观察者模式。例如：
控制器对象在每轮开始时产生一个玩家船舶对象。控制器要求工厂提供船舶。除其他外，该船还依赖于可能使船舶过热和毁坏的反应堆物体。工厂注入这些依赖项。到目前为止，非常好。
现在，HUD需要知道船的状态，特别是反应堆温度，但是在DI意义上HUD并不依赖依赖：HUD在船舶出现之后仍然存在破坏。
问题是，假设控制器没有HUD的参考，我怎样才能让HUD与船舶联系？这只是一个很小的例子。我有很多很多需要将事件传递给对方的对象。
我觉得我可以在工厂做一些布线，但感觉“错误”，并且在现有订阅需要更改的情况下无效。
无论如何，我读到的关于观察者模式的一切都忽略了这个更广泛的问题。是否有既定的解决方案？
答案 0 :(得分：2)
Castle Windsor有一个设施......呃...促进这个:-) 它被称为EventWiring Facility。
请参阅：
如果.NET不是您的平台，您仍然可能希望从中获取想法。
答案 1 :(得分：0)
您可能希望探索使用更通用的内容，例如“事件聚合器”或中央消息/事件取消机制来执行此操作。这样你的HUD就可以简单地订阅它关心的事件类型，你的船只可以根据需要提升/发送这些事件，而且两者都不需要真正了解另一个。这是很好地分离事物的一种方法。
无法为您找到一个好的全能链接，但这里讨论的是与winforms应用程序相关的想法：http://www.lostechies.com/blogs/derickbailey/archive/2009/12/22/understanding-the-application-controller-through-object-messaging-patterns.aspx
答案 2 :(得分：0)
实施设计模式通常涉及自己对参与者进行编码：主题＆amp;观察者，在这种情况下。这些物体如何形成规定关系的细节实际上（通常）取决于您。您可以自由使用Spring DI（Java）或任何对您有意义的框架。
但我不确定这些关系是典型DI框架的良好素材。您的主题 - 以及您的观察者 - 可能会在游戏过程中经常进入/离开。
也许你还需要一些观察者来观察产生你的主题的工厂。通过这种方式，他们可以获得他们可能想要跟踪的新主题的通知，并将自己注册为观察者。