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

Question

我正在做我自己的研究项目，我正在为正确的建筑/设计模式的选择而奋斗。

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

所以我的问题是-什么软件架构/设计模式可以应用到这个特定的项目？如何组织类/对象之间的相互作用？如何创建对象？

例如，“事件驱动架构”或“微内核”可以在这里应用吗？我们将非常感谢对有用资源的引用！非常感谢您提前！

Answer 1

小心设计模式。如果您将它们分散到代码中，希望一切都能正常工作，那么很快就会有一个无法读懂的样板混乱不堪。它们是菜谱，不是解决方案。

我给你的建议是，挑选一张纸和一支铅笔，开始绘制你领域的所有实体，以及它们的所有必要条件，看看它们之间的关系。如果您想认真对待它，可以做一些类似于这的事情。

在定义实体时，要努力实现高内聚性和松散耦合。

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

至于松散耦合，这意味着您的实体应该相互独立。使用上面的例子，假设您现在是两个高度内聚类的骄傲所有者-一个从文件中读取内容(Reader)，另一个处理这个类(处理器)。现在，假设处理器类有Reader类的一个实例，并调用它以获取它的输入。在这种情况下，我们可以说这两个类是紧密耦合的，因为没有Reader处理器就不能工作。在面向对象的世界中，解决方案通常是使用接口。您可以找到一个简洁的示例这里。

在定义了域的初始模型并收集了尽可能多的相关知识之后，您现在可以开始考虑实现的体系结构了。这是你可以开始思考的架构模式。事件驱动架构，干净架构，MVP，MVVM.这都将取决于您的域名。知道哪种模式最适合你是你的工作。剧透警报:即使对有经验的工程师来说，这也是非常困难的，所以不要害怕失败。

最后，将设计模式留给实现阶段。它们的使用完全取决于您的实现问题和决定。还有，不要强迫他们。理想情况下，您将解决一个问题，如果适用的话，您将看到一个模式出现。相信我，你最不想要的就是有一箱设计模式。无论如何，如果您需要关于模式的文献，我完全推荐这本书。不管你是工程师，这都是很棒的。

进一步读：

• 固体原理
• 洋葱建筑
• 洁净建筑

祝好运!

Answer 2

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

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

Answer 3

如果你检查一本关于设计模式的书，那就好多了。我真的很喜欢这个。

例如，如果您需要从某个特定对象获取一些数据，您可能需要观察者模式为您工作，并且一旦对象有了数据，您(或其他对象)就会了解该数据并能够使用它，使用另一种模式(策略可能有效，这实际上取决于您必须做什么)。

如果您必须同时做一些事情，也可以检查Singleton模式(好，检查最重要的！)