所以，我再次回过头来问一个与模式相关的问题。这可能过于通用而无法回答，但我的问题是这个（我正在编程并应用我在学习过程中学到的概念）：
我在结构中有几个结构（注意，我在一般意义上使用的是结构这个词，而不是严格的C struct意义上的（哇，这是一个绕口令） ），以及相当复杂的相互通信。使用我之前的一个问题的示例，我有Unit个对象，UnitStatistics个对象，General个对象，Army个对象，Soldier个对象，{{1对象，列表继续，一些组织在树结构中。
经过一番研究并四处询问之后，我决定使用中介模式，因为相互依赖性变得太过分了，而且这些类开始显得过于紧密耦合（是的，我刚刚学到的另一个术语，我是太高兴不在某处使用它）。这种模式非常有意义，它应该能够理解我目前在项目中煮沸的一些混乱的意大利面。
但是，我想我还没有完全了解OO设计。我的问题是这个（最后.PS，我希望它有意义）：我应该有一个中央调解员来处理程序中的所有通信，甚至可能吗？或者，我应该为每个结构类型提供一个抽象调解器和一个子类调解器，用于处理特定类集的通信，例如：每个军队的具体调解员，帮助军队，将军，其部队等。
我更倾向于第二种选择，但在OO设计方面，我真的不是专家。所以第三个问题是，我应该阅读什么来更多地了解这类主题（我看过Head First的设计模式和GoF书，但他们更像是“学习词汇” “有点书而不是”学习如何使用你的词汇“这种书，这是我在这种情况下所需要的。
一如既往，感谢任何和所有帮助（包括诙谐的评论）。
答案 0 :(得分：3)
我认为您没有提供足够的信息以便能够做出明智的决定。
通过查看您的其他问题，似乎大多数通信都发生在Army内的组件之间。你没有提到在一个Army和另一个Mediator之间发生的事情。在这种情况下，让每个Army实例在包含单个Generals的组件之间进行协调通信似乎是有意义的 - 即Soldiers，Army等等。所以如果你有10个ArmyMediator，那么你将有10 {{1}}个。
如果你真的想学习O-O设计，你将不得不尝试一下，并冒着不时出错的风险。我认为你将学习同样多的东西，如果不是更多的话，必须重新构建一个不能完全模拟问题的设计，而不是那样，就像你第一次使设计正确一样。
通常，您无法预先获得足够的信息，无论如何都无法从中选择正确的设计。只需选择目前最简单的一种，并在以后更好地了解当前设计的要求和/或缺点时进行改进。
关于书籍，我个人认为如果你更少关注他们描述的特定模式集，那么GoF书会更有用，并且更多地关注将类分解为更小的可重用组件的整体方法，每个组件通常封装一个单一功能单元。
答案 1 :(得分：2)
我无法直接回答你的问题，因为我从未使用过这种设计模式。但是，每当我遇到这个问题时，在各种对象之间传递消息，我就会使用信号槽模式。通常我使用Qt's，但我的第二个选项是Boost's。它们都通过使用单个全局消息传递处理程序来解决问题。它们在类型安全方面都非常有效，无论是在cpu周期还是在生产力方面。因为它们是如此灵活，即任何物体并发出任何信号，而任何其他物体都可以接收任何信号，我认为你最终会解决你所描述的内容。
很抱歉，如果我只选择了2选项中的任何一个，而不是添加第3个选项，那就更糟糕了！
答案 2 :(得分：2)
要使用Mediator，您需要确定： （1）需要调解的对象组由什么组成？ （2）其中，哪些是具有共同界面的？
Mediator设计模式依赖于要调解的具有“公共接口”的对象组;即，相同的基类：GoF书籍示例中的小部件继承自相同的Widget基础等。
因此，对于您的申请： （1）哪些结构（士兵，将军，军队，单位等）需要相互调解？ （2）其中哪些（士兵，将军，陆军，部队等）有共同基础？
这可以帮助您确定Mediator设计模式中参与者的大纲，作为第一步。您可能会发现（1）中的某些结构不属于（2）。然后，你可能需要强迫他们坚持一个共同的界面，如果你可以改变它，或者你可以负担来做出改变......（可能会变得过多重新设计工作它违反了开放原则：你的设计应该尽可能地增加新功能，但不能修改现有的功能。）
如果您发现上面的（1）和（2）导致了不同组的分区，每个组都有自己的中介，那么这些分区的数量决定了不同类型的中介的数量。现在，这些不同的调解员是否应该拥有自己的共同界面？也许，也许不是。多态性是一种通过在公共接口下对不同实体进行分组来处理复杂性的方式，使得它们可以作为一个组而不是单独地处理。那么，在一个共同的界面下对所有这些所谓的不同类型的调解员进行分组会有什么好处（比如GoF书中的DialogDirector）？可能，如果： （a）您可能必须使用异构的调解员集合; 要么 （b）您将来会想到这些调解员会发展（他们可能会）。因此，提供一个抽象接口可以让您在不影响现有媒体或同事（调解者的客户）的情况下推导出更多进化版本的调解员。
所以，在不知道更多的情况下，我不得不猜测，是的，使用抽象调解器并将它们子类化，用于每个组分区可能更好，只是为了为将来的更改做好准备无需重新设计调解员（请记住开放式封闭原则）。
希望这有帮助。