使用模块/中介/外观模式管理分层任务答案

【问题标题】：Managing hierarchical tasks with module/mediator/facade pattern使用模块/中介/外观模式管理分层任务
【发布时间】：2015-03-09 00:52:01
【问题描述】：

假设我有一个非常密集的程序任务要完成，big task，它可以分解成更小的定义明确的子任务：

每个子任务从父任务中获取数据，运行相关计算，然后将结果返回给父任务，以此类推，直到big task完成。

我还在学习模块/中介/外观模式，但据我了解，架构应该是这样的：

父任务会发布指令（子任务会听到），子任务会在完成时发布结果（父任务会听到）。

我的理解正确吗？ Addy Osmani 的解释非常有帮助，但他并没有过多地谈论用于复杂系列计算的模块。也许这种类型的项目有更好的设计模式？谢谢。

【问题讨论】：

【解决方案1】：

你确定你真的需要在这里使用这么多设计模式吗？

如果您只有一系列嵌套的独立任务，为什么不将它们结构化为matryoshka doll？

你可能有一个抽象的 Task 类，它允许自己有孩子。也不能有孩子。此类可能还具有 calc() 函数，如果需要，该函数会启动子级进行计算，组合结果并向父级返回一些值。您必须将一些逻辑抽象到 Task 中，但这样的方案可以降低复杂度。

然后，您将拥有 Task 的特定后代来执行不同类型的计算。您可以将此类任务的配置存储在 JSON 或 XML 文件中。

使用各种图案看起来很漂亮很酷，但是如果根本不需要它们的话……

我错过了什么吗？

【讨论】：

嘿，你给了我一些很好的思考点，谢谢。我的应用程序比单个分层任务复杂得多，所以我肯定需要使用设计模式，但也许你是对的，我可以在具有“嵌套”依赖关系的单个模块中进行大型计算。我不完全确定这将如何工作......
FractalizeR 在这里描述了复合模式。以github.com/iluwatar/java-design-patterns#composite 为例。
@JoeRocc 欢迎您。我从来没有完整地看过你的申请，所以我不能提出一些非常具体的建议。但基本思想是编写尽可能简单的代码（被某人描述为“模式”与否 - 没关系）。不要为了它而急于使用 OOP 模式。