我作为一名开发人员在内部串行终端应用程序上工作。我的目标是编写一个足够灵活的框架，以便我可以使用它来创建三个独立的应用程序:
- 串行终端应用程序(很像 super 终端)
- 数据分析应用程序(将按照一定的标准对序列数据进行排序和显示)
- 解码应用程序(将处理串行数据并显示来自数据库的相关信息)
在未来的某个时候，我想将这三个应用程序合并为一个。然而，这远非优先事项。
我将框架分为三个独立的部分 - GUI( View 界面)、后端( Controller 界面)和设置处理程序(ISettingsHandler 界面)。但是，我已经遇到了一些循环依赖问题(必须将 ISettingsView 移动到与 ISettingsHandler 相同的命名空间)，这表明 future 会有更多麻烦。
我对每个应用程序的要求如下:
- 串行终端 - GUI 必须能够与串行端口传输数据、显示和修改设置以及发送文件
- 串行分析应用程序 - GUI 必须能够检索传入的串行数据并显示和修改设置
- 解码应用程序 - GUI 必须能够检索传入的串行数据
我是不是把它弄得比它应该的更复杂了？我知道我可以用更少的接口(interface)完成同样的事情，但我担心这个框架在未来使用时的灵 active 。有没有适合这种场景的设计模式？
编辑:澄清一下，框架的三个“部分”中的每一个都在不同的命名空间中。
我已经修复了循环依赖，但是，我仍然不确定这是否是该应用程序的最佳设计模式。有什么建议吗？
最佳答案
设计原则之一是“好莱坞原则”，即“你不打电话，我们会调用你”(来自 Head first 设计模式)
循环依赖是一个常见的问题。为避免这种情况，请遵循此原则。
不要在下层引用上层接口(interface)/类。高层类应该使用底层接口(interface)/类。
例如，ISettingsHandler 应该引用 IController 而不是其他方式。即使在实现具体类时也要尝试遵循该原则。
您的代码将更易于维护。
关于c# - 串行终端应用程序的设计模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4865262/