如何以模块化的方式设计应用程序？
我正在寻找有关“如何以模块化方式设计应用程序”的指示、建议、链接、警告、想法甚至轶事。我将在这个项目中使用 python，但建议不一定要参考这种语言，尽管我只愿意实现基于 OOP 的设计。
这里有一些上下文可以帮助您了解我来自哪里以及做什么我正在尝试实现...
我的项目将是一个小型应用程序，它将使用 Web 服务并以多种方式显示结果，包括：
- 调用选项卡的结果
- 通知弹出窗口仅包含应用程序主窗口中的 从检索到的消息原始数据
- 缓冲区绘制的图形（按需可见），其中来自各种服务的结果将堆积
该应用程序将作为免费（如语音）软件发布，因此我想使其他开发人员可以轻松编写插件/模块，从而扩展主应用程序的功能，而无需更改核心代码。
此时，插件本质上应该使开发人员能够通过定义提供者、数据操作（如果有）以及向用户呈现数据的方式来激活新的 Web 服务。
我在使用 drupal 进行开发方面拥有丰富的经验，它具有强大的模块化方法，但也遵循非面向对象的设计，所以我怀疑对于python来说，drupal设计可能不是最优的解决方案。
如果这很重要的话——核心将为 GNU/Linux 原生开发。
预先感谢您的宝贵时间！
I am looking for pointers, suggestions, links, warnings, ideas and even anecdotical accounts about "how to design an application in a modular way". I am going to use python for this project, but advice does not need to necessarily refer to this language, although I am only willing to implement a design based on OOP.
Here's some context to understand where I come from and what I am trying to achieve...
My project will be a small application that will consume web services and display the results in a variety of ways, including:
- notification popup containing just the result of the call
- tab in the main window of the application with graphics plotted from retrieved raw-data
- buffer of messages (visible on domand) where results from various services will pile up
The application will be released as free (as-in-speech) software, and for this reason I would like to make it really easy for other devs to write plugins/modules that will extend the functionality of the main application without needing to change the core code.
At this point in time, plugins should essentially enable a developer to activate a new webservice, by defining the provider, the data manipulation (if any) and the way the data will be presented to the user.
I have extensive experience in developing with drupal which has a powerful modular approach, but that also follows a non-object-oriented design, so I suspect that for python, drupal design might not be the optimal solution.
If this is of any importance - the core will be natively developed for GNU/Linux.
Thank you in advance for your time!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
尝试保持事物松散耦合，并大量使用接口来提供帮助。
我会从关注点分离开始设计。主要的架构层是：
域类完成工作，但不了解 UI。持久层了解域类，足以根据需要保存/加载。系统接口层抽象了外部系统，使您可以在测试时在后面插入模拟器。理想情况下，UI 应使用 MVC，以获得最大的灵活性。
不说太多，人们通常不会将 Drupal 视为优秀架构设计的典范。它已经相当有机地发展，并且设计发生了许多变化，系统升级时经常出现的插件损坏就证明了这一点。
我也会回应 MicSim 所说的，关于仔细设计插件界面并编写多个不同的插件来练习它。这是真正充实应用程序和插件如何交互的问题的唯一方法。
Try to keep things loosely coupled, and use interfaces liberally to help.
I'd start the design with the Separation of Concerns. The major architectural layers are:
The domain classes do the work, but don't know about the UI. The persistence layer knows about the domain classes, enough to save/load as required. The system interface layer abstracts away external systems, which lets you plug a simulator in behind while testing. The UI should ideally use MVC, for maximum flexibility.
Without putting too fine a point on it, one would not ordinarily look to Drupal as an exemplar of good architectural design. It has grown rather organically, and there have been many upheavals of the design, as evidenced by the regular plugin breakage upon system upgrades.
I would also echo what MicSim said, regarding carefully designing the plugin interface and writing multiple different plugins to exercise it. This is the only way to really flesh out the issues of how the app and plugins interact.
由于您将通过应用程序提供一些基本功能，因此请确保您自己将可扩展/可替换的部分编码为插件。然后您将最好地了解您的 API 应该是什么样子。
为了证明 API 是好的，你应该编写第二个和第三个插件，因为那时你会发现你在编写第一个插件时做了很多假设。通常，在完成第二步和第三步之后，事情会变得更加清晰。
现在，您应该再编写一个插件，因为您编写的最后一个插件在类型、输入数据和表示方面类似于第一个插件（可能是另一个天气 Web 服务）。选择完全不同的东西，使用完全不同的数据，你会发现你的 API 仍然过于定制。 （否则你做得很好！）
As you will deliver some basic functionality with your app, make sure that you code the part that should be extendable/replaceable already as a plugin by yourself. Then you'll best get a feeling about how your API should look like.
And to prove that the API is good, you should write a second and third plugin, because then you will discover that you made a lot of assumptions when writing the first one. Normally things clear up a bit after doing this 2nd and 3rd step.
Now, you should write one more plugin, because the last plugins you wrote resemble the first one in type, input data and presentation (maybe yet another weather webservice). Choose something total different, with absolutely different data, and you will see your API being still too tailored. (Else you did a good job!)
好吧，可能首先要坐下来弄清楚插件可能需要什么来实现其目的。
您需要在设计中考虑两个主要方面。
也许也是，因为这听起来像是一个学习项目。
我还建议您在设计 API 时开发一些基本插件。必须实际使用您的设计的经验将使您能够看到给定的方法可能会使事情变得比实际需要的更困难。
Well, probably the first place to start is to sit down and figure out what the plug-in might need to fulfill its purpose.
You'd want to consider two main aspects in your design.
And probably also, since this sounds like a learning project.
I'd also recommend developing some basic plugins as you design the API. The experience of having to actually use what you design will allow you to see where a given approach might be making things harder than they need to be.
查看侦听者-订阅者模式。迟早，您的应用程序将变得足够复杂，您需要实现回调。当您达到该限制时，请使用侦听器订阅者（wxPython 中有一个实现）。
例如，多个模块想要从多个提要中监视新数据。链接在一起的模块可能希望根据新数据进行自我更新。
Look into the listener-subscriber pattern. Sooner or later, your app will be complex enough that you need to implement callbacks. When you hit that limit, use listener-subscriber (there's an implementation in wxPython).
For example, several modules will want to watch for new data from a number of feeds. Modules that link together might want to update themselves, based on new data.