所以，我又回来问了一个与模式相关的问题。这可能太笼统而无法回答，但我的问题是这个(我正在编程并应用我在前进过程中学到的概念):
我在结构中有几个结构(请注意，我在一般意义上使用 structure 这个词，而不是严格的 C struct 意义上的(哇，多好的绕口令))，以及相当多的复杂的相互交流。以我之前的一个问题为例，我有 Unit 对象、UnitStatistics 对象、General 对象、Army对象、Soldier 对象、Battle 对象，等等等等，有些以树形结构组织。
经过一些研究和四处询问后，我决定使用调解器模式，因为相互依赖变得有点太多了，而且类开始显得过于紧密耦合(是的，我刚刚学到的另一个术语很高兴不在某个地方使用它)。这个图案非常有意义，它应该能理顺我目前在我的项目锅里煮的一些困惑的意大利面。
但是，我想我对 OO 设计的了解还不够。我的问题是(最后。PS，我希望它有意义):我是否应该有一个中央调解员来处理程序内的所有通信，甚至可能吗？或者我应该说，每个结构类型都有一个抽象中介和一个子类中介来处理一组特定类的通信，例如每个军队都有一个具体的调解人，帮助军队、将军、单位等。
我更倾向于第二种选择，但在 OO 设计方面我真的不是专家。所以第三个问题是，我应该阅读哪些内容才能更多地了解此类主题(我看过 Head First 的设计模式 和 GoF 书，但它们更像是“学习词汇表” "比“学习如何使用你的词汇”这样的书，这正是我在这种情况下需要的。
一如既往，感谢您提供的所有帮助(包括机智的评论)。
最佳答案
我认为您在上面提供的信息不够多，无法就哪个是最好的做出明智的决定。
从您的其他问题来看，大多数通信似乎发生在 Army 中的组件之间。你没有提到一支 Army 和另一支军队之间发生的事情。在这种情况下，让每个 Mediator 实例协调组成单个 Army 的组件之间的通信似乎是有意义的 - 即 Generals，Soldiers 等。所以如果你有 10 个 Army，那么你将有 10 个 ArmyMediator。
如果你真的想学习 O-O 设计，你将不得不尝试一些东西，并冒着不时犯错的风险。我认为，从必须将不能完全正确模拟问题的设计重构为正确模拟问题的设计中，您将学到的东西和第一次就正确设计一样多，甚至更多。
通常，您事先没有足够的信息来选择合适的设计。只需选择目前可行的最简单的一个，然后在您更好地了解当前设计的要求和/或缺点时对其进行改进。
关于书籍，我个人认为如果您较少关注它们描述的特定模式集，而更多关注将类分解为更小的可重用组件的整体方法，我个人认为 GoF 这本书更有用，每个组件通常封装一个单一功能单元。
关于c++ - 更多关于中介者模式和 OO 设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3182443/