我正在做自己的研究项目，并且在正确选择架构/设计模式方面非常挣扎。
在这个项目中，“系统”启动后，我需要在后台做一些事情（任务、处理、显示数据等），同时能够使用键盘与系统交互并发送一些命令，例如“给我这个特定对象的状态”或“这个对象中的数据是什么”。
所以我的问题是——什么样的软件架构/设计模式可以应用于这个特定的项目？类/对象之间的交互应该如何组织？对象应该如何创建？
例如，“事件驱动架构”或“微内核”可以在这里应用吗？非常感谢对有用资源的一些参考！非常感谢您！
问问题
556 次
3 回答
3
小心设计模式。如果你把它们撒在你的代码中，希望一切都很好，你很快就会遇到一个难以阅读的样板文件。它们是食谱，而不是解决方案。
我对你的建议是选择一张纸和一支铅笔，开始绘制你领域中的所有实体，以及它们的所有必需品，然后看看它们之间的关系。如果你想认真一点，你可以做这样的事情。
在定义实体时，请争取高内聚和松耦合。
高内聚意味着您应该将相似的功能保持在一起。在一个非常简单的示例中，如果您有一个从文件中读取内容并对其进行处理的类，则该类的内聚性较低，因为读取和处理是两个非常不同的功能。在这种情况下，您需要为每个功能创建一个类。
至于松散耦合，这意味着您的实体应该相互独立。使用上面的示例，假设您现在拥有两个高度内聚的类——一个从文件中读取内容（Reader），另一个处理该内容（Processor）。现在，假设 Processor 类有一个 Reader 类的实例，并调用它以获取其输入。在这种情况下，我们可以说这两个类是紧密耦合的，因为 Processor 没有 Reader 就无法工作。在 OOP 世界中，解决方案通常是使用接口。你可以在这里找到一个简洁的例子。
在定义了域的初始模型并尽可能多地收集了有关它的知识之后，您现在可以开始考虑实现的架构了。这是您可以开始考虑架构模式的地方。事件驱动架构、干净架构、MVP、MVVM……这一切都取决于你的领域。知道哪种模式最适合是您的工作。剧透警告：即使是经验丰富的工程师也很难正确地做到这一点，所以不要害怕失败。
最后，将设计模式留给实施阶段。它们的使用完全取决于您的实施问题和决定。另外，不要强迫他们。理想情况下，你会解决一个问题，如果适用，你会看到一个模式出现。相信我，你最不想要的就是有一个design patternitis的案例。无论如何，如果您需要有关模式的文献，我完全推荐这本书。无论您作为工程师的水平如何，这都很棒。
进一步阅读：
祝你好运！
于 2018-10-23T16:16:31.257 回答
1
您有一个后台任务，它确实可以用于消息泵/事件队列。然后您的前台任务将向该后台线程发送请求并异步等待结果。
看看“并行编程模式”一书。
于 2018-10-23T09:31:04.387 回答
0
如果您查看有关设计模式的书，那就更好了。我真的很喜欢这个。
例如，如果您需要从特定对象获取一些数据，您可能需要观察者模式为您工作，并且一旦对象拥有数据，您（或另一个对象）就可以了解这些数据并可以使用它，使用另一种模式（策略可能有效，这真的取决于你必须做什么）。
如果你必须同时做一些事情，还要检查单例模式（好吧，检查最重要的！）。
于 2018-10-23T09:41:13.090 回答