python 如何以模块化的方式设计应用程序？

How to design an application in a modular way?

提问by mac

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.

我正在寻找关于“如何以模块化方式设计应用程序”的指针、建议、链接、警告、想法甚至轶事。这个项目我打算用python，但是advice不一定非要指这种语言，虽然我只愿意实现一个基于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:

我的项目将是一个小型应用程序，它将使用 Web 服务并以多种方式显示结果，包括：

• 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

• 仅包含调用结果的通知弹出窗口
• 应用程序主窗口中的选项卡，其中包含从检索到的原始数据绘制的图形
• 消息缓冲区（在 domand 上可见），各种服务的结果将在其中堆积

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/modulesthat will extend the functionality of the main application without needing to change the core code.

该应用程序将作为免费（as-in-speech）软件发布，出于这个原因，我想让其他开发人员能够轻松编写插件/模块，这些插件/模块将扩展主应用程序的功能，而无需更改核心代码。

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 drupalwhich 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.

我在使用具有强大模块化方法的drupal进行开发方面拥有丰富的经验，但这也遵循非面向对象的设计，因此我怀疑对于 python，drupal 设计可能不是最佳解决方案。

If this is of any importance - the core will be natively developed for GNU/Linux.

如果这很重要 - 核心将是为 GNU/Linux 本地开发的。

Thank you in advance for your time!

提前感谢您的时间！

采纳答案by gavinb

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:

我会从关注点分离开始设计。主要的架构层是：

• Problem Domain (aka. Engine, Back-end): the domain classes, which do all the actual work, have domain knowledge implement domain behaviour
• Persistence: storage management for domain classes, database/filesystem layer
• User Interface: the GUI, which talks to the domain classes
• System Interfaces: talking to other systems, eg. networking, web services

• 问题域（又名引擎，后端）：完成所有实际工作的领域类，具有领域知识实现领域行为
• 持久性：域类、数据库/文件系统层的存储管理
• 用户界面：GUI，与域类对话
• 系统接口：与其他系统交谈，例如。网络、网络服务

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.

域类完成工作，但不了解 UI。持久层知道域类，足以根据需要保存/加载。系统接口层抽象出外部系统，这让您可以在测试时在后面插入模拟器。理想情况下，UI 应该使用 MVC，以获得最大的灵活性。

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.

如果没有对它进行过多的说明，人们通常不会将 Drupal 视为良好架构设计的典范。它已经相当有机地发展了，并且设计上发生了许多剧变，系统升级时经常出现的插件损坏就证明了这一点。

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.

我也会回应 MicSim 所说的，关于仔细设计插件界面并编写多个不同的插件来练习它。这是真正充实应用程序和插件如何交互的问题的唯一方法。

回答by MicSim

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.

由于您将通过应用程序提供一些基本功能，因此请确保您自己将应该可扩展/可替换的部分编码为插件。然后，您将最好地了解您的 API 应该是什么样子。

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.

而且为了证明API好，你应该写第二个和第三个插件，因为那样你会发现你在写第一个的时候做了很多假设。通常情况下，在完成第二步和第三步之后，事情会好转一些。

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 仍然过于定制。（否则你做得很好！）

回答by Adam Luchjenbroers

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.

您需要考虑设计中的两个主要方面。

• How will your framework pass requests / receive responses from the plug-in?
• What helper classes or modules might be good to provide?

• 您的框架将如何传递请求/接收来自插件的响应？
• 提供哪些帮助类或模块可能是好的？

And probably also, since this sounds like a learning project.

而且可能也是，因为这听起来像是一个学习项目。

• What do you want to write yourself, and what are you happy just to pick out of an existing library?

• 你想自己写什么，从现有的图书馆中挑选出什么让你高兴？

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.

我还建议您在设计 API 时开发一些基本插件。必须实际使用你设计的东西的经验会让你看到给定的方法可能会使事情变得比他们需要的更难。

回答by miku

• design the api for your app, carefully (How To Design A Good API and Why it Matters)
• make everything, which could be used independently a module, then group and build larger parts out of the simple parts (KISS)
• don't repeat yourself (DRY)
• write/publish short documentation frequently, for yourself and others (open source mantra) ...

• 仔细为您的应用程序设计 api（如何设计一个好的 API 以及为什么它很重要）
• 把可以独立使用的所有东西都做成一个模块，然后从简单的部分中组合和构建更大的部分（KISS）
• 不要重复自己（干）
• 经常为自己和他人编写/发布简短的文档（开源口头禅）...

回答by wisty

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).

查看侦听器-订阅者模式。迟早，您的应用程序将足够复杂，您需要实现回调。当您达到该限制时，请使用 listener-subscriber（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.

例如，多个模块需要从多个提要中观察新数据。链接在一起的模块可能希望根据新数据自行更新。