如何选择正确的架构/设计模式

Question

我正在做我自己的研究项目，并且在正确选择架构/设计模式方面非常挣扎。

在这个项目中，“系统”启动后，我需要在后台做一些事情（任务、处理、显示数据等），同时能够与系统交互，例如键盘和发送一些命令，例如“给我这个特定对象的状态”或“这个对象中的数据是什么”。

所以我的问题是 - 哪些软件架构/设计模式可以应用于这个特定项目？类/对象之间的交互应该如何组织？对象应该如何创建？

可以在这里应用“事件驱动架构”或“微内核”吗？非常感谢对有用资源的一些参考！ 非常感谢您！

Answer 1

您有一个后台任务，它确实可以用于消息泵/事件队列。然后你的前台任务会向这个后台线程发送请求并异步等待结果。

看看“并行编程模式”一书。

Answer 2

如果您查看有关设计模式的书籍会更好。 I really like this one。

例如，如果您需要从特定对象获取一些数据，您可能需要观察者模式来为您工作，并且一旦对象拥有数据，您（或另一个对象）就会知道这些数据并可以使用它，使用另一种模式（策略可能有效，这真的取决于你必须做什么）。

如果你必须同时做一些事情，还要检查单例模式（好吧，检查最重要的！）。

Answer 3

小心设计模式。如果你把它们撒在你的代码中，希望一切都很好，你很快就会遇到一个难以阅读的样板文件。它们是食谱，而不是解决方案。

我对您的建议是选择一张纸和一支铅笔，然后开始绘制您域中的所有实体及其所有必需品，然后看看它们之间的关系。如果您想认真对待它，可以执行this 之类的操作。

在定义实体时，争取高内聚和松散耦合。

高内聚意味着您应该将相似的功能保持在一起。在一个非常简单的示例中，如果您有一个从文件中读取内容并对其进行处理的类，则该类的内聚性较低，因为读取和处理是两个非常不同的功能。在这种情况下，您需要为每个功能创建一个类。

对于松散耦合，这意味着您的实体应该相互独立。使用上面的示例，假设您现在拥有两个高度内聚的类——一个从文件中读取内容（Reader），另一个处理该内容（Processor）。现在，假设 Processor 类有一个 Reader 类的实例，并调用它以获取其输入。在这种情况下，我们可以说这两个类是紧密耦合的，因为没有 Reader，Processor 将无法工作。在 OOP 世界中，解决方案通常是使用接口。你可以找到一个简洁的例子here。

在定义了您的域的初始模型并尽可能多地收集了有关它的知识之后，您现在可以开始考虑实现的架构了。这是您可以开始考虑架构模式的地方。事件驱动架构、干净架构、MVP、MVVM ......这一切都取决于你的领域。知道哪种模式最适合是您的工作。剧透警告：即使是经验丰富的工程师也很难正确做到这一点，所以不要害怕失败。

最后，将设计模式留给实施阶段。它们的使用完全取决于您的实施问题和决定。另外，不要强迫他们。理想情况下，你会解决一个问题，如果适用，你会看到一个模式出现。相信我，您最不想要的就是拥有design patternitis 的案例。无论如何，如果您需要有关模式的文献，我完全推荐this book。无论您作为工程师的水平如何，这都很棒。

进一步阅读：

• SOLID principles
• Onion Architecture
• Clean architecture

祝你好运！