如何以模块化方式设计应用程序？
我在寻找一些建议、链接、警告、想法，甚至是关于“如何以模块化的方式设计一个应用程序”的经验分享。我将使用Python来做这个项目，但建议不一定要和这个语言有关，不过我只想基于面向对象编程（OOP）来实现设计。
这里有一些背景信息，帮助你理解我的出发点和目标……
我的项目将是一个小应用，它会调用网络服务，并以多种方式展示结果，包括：
- 弹出通知，里面只有调用的结果
- 应用主窗口中的一个标签，显示从获取的原始数据绘制的图形
- 消息缓冲区（按需可见），各种服务的结果会在这里堆积
这个应用将作为免费软件发布，因此我希望让其他开发者很容易编写插件/模块，以扩展主应用的功能，而不需要修改核心代码。
目前，插件基本上应该让开发者能够激活一个新的网络服务，通过定义提供者、数据处理（如果有的话）以及数据如何呈现给用户。
我在开发方面有丰富的经验，尤其是使用Drupal，它有强大的模块化设计，但它也不是面向对象的设计，所以我怀疑对于Python来说，Drupal的设计可能不是最优的解决方案。
如果这有任何重要性——核心将原生开发为GNU/Linux。
提前感谢你的时间！
5 个回答
首先，最好的起点就是坐下来想一想，这个插件需要什么才能完成它的功能。
在设计的时候，你需要考虑两个主要方面。
- 你的框架将如何发送请求和接收来自插件的响应？
- 有哪些辅助类或模块可以提供帮助？
另外，因为这听起来像是一个学习项目。
- 你想自己写哪些部分，哪些部分你可以直接从现有的库中拿来用？
我还建议在设计API的时候，先开发一些基本的插件。亲自使用你设计的东西，可以帮助你发现某些方法可能让事情变得比必要的更复杂。
当你开始开发应用程序的一些基本功能时，确保你自己编写的那部分可以扩展或替换的功能，最好是做成一个插件。这样你就能更好地理解你的API（应用程序接口）应该是什么样子的。
为了证明你的API设计得不错，你应该再写一个或两个插件。这样你会发现，在写第一个插件的时候，你做了很多假设。通常在完成第二个和第三个插件后，事情会变得更加清晰。
接下来，你应该再写一个插件，因为你之前写的插件在类型、输入数据和展示方式上可能和第一个插件很相似（比如又是一个天气服务）。这次选择一个完全不同的主题，使用完全不同的数据，你会发现你的API可能还是太过于特定化了。（如果没有，那你就做得很好！）
尽量让各个部分之间的联系松散一些，多使用接口来帮助实现这一点。
我会从关注点分离开始设计。主要的架构层次包括：
- 问题领域（也叫引擎、后端）：这些是负责实际工作的领域类，它们拥有领域知识并实现领域行为。
- 持久层：负责管理领域类的存储，比如数据库或文件系统。
- 用户界面：就是图形用户界面（GUI），它与领域类进行沟通。
- 系统接口：与其他系统进行交流，比如网络或网络服务。
领域类负责具体的工作，但它们并不知道用户界面是什么。持久层了解领域类，能够根据需要进行保存和加载。系统接口层则把外部系统抽象化，这样在测试时可以方便地插入模拟器。用户界面最好使用MVC模式，这样可以获得最大的灵活性。
不想过于严肃地说，Drupal通常并不是一个好的架构设计的典范。它是逐渐发展起来的，设计上经历了很多波动，这也导致了系统升级时插件经常出现问题。
我也赞同MicSim的观点，关于仔细设计插件接口，并编写多个不同的插件来测试它。这是唯一能真正发现应用程序和插件之间互动问题的方法。