从 wx 框架类调用应用程序方法答案

【问题标题】：Calling Application Methods from a wx Frame Class从 wx 框架类调用应用程序方法
【发布时间】：2008-12-24 06:07:30
【问题描述】：

我是从 wxPython 开始的，并且一直在努力完成我可以掌握的每个教程和示例。然而，我遇到了一个小问题，它与 wx.App 与 wx.Frame 有关，并且应该包含特定的方法。几乎我见过的每个示例都没有超出布局/大小调整和事件处理，没有一个真正涉及 wxPython 项目的项目组织。

例如，我有一个获取文件夹列表的方法。大多数示例处理此问题的方式是将方法直接粘贴在框架类中。此方法有可能在应用程序的其他几个部分中使用，因此将其存储在应用程序类级别会更有意义。

我应该如何组织和调用这样的“通用”方法，以免我的框架类混乱。

更新：

为了澄清，“文件夹列表”只是一个例子，我的实际方法做了很多工作。我要说的是我的代码不是特定于框架的。如果我在应用程序类中有这个，那么从我的框架中的事件方法调用它的最佳方法是什么。

我正在寻找实际的项目组织技术，而不是编程基础知识。

【问题讨论】：

如果你真的在学习冒险并且你没有时间紧迫，那么你可以浏览 Audacity 应用程序的源代码。这是一个非常成功的、非基本的、非平凡的应用程序，它恰好是开源的 AND 使用 wxWidgets。 audacity.sourceforge.net

【解决方案1】：

从 wxWidgets/wxPython 数据类型继承的类不应实现任何业务逻辑。 wxWidgets 是一个 GUI 库，因此 wxApp 或 wxFrame 的任何子类都应该专注于 GUI，即显示界面和响应用户操作。

做一些有用的事情的代码应该从 wx 中分离出来，因为你可以稍后决定在一些 web 或控制台应用程序中使用它，并且你不想在这种情况下创建 wxApp 对象。您还可以稍后决定将一些计算移动到单独的“工作线程”，而您的 GUI 将成为“主线程” - 响应式，并在长期计算期间正确重新绘制。

最后但并非最不重要的一点 - 封装逻辑的类可能会在项目生命周期内增长。如果它们与您的 GUI 类混合在一起，它们会增长得更快，最后它们变得如此复杂以至于您几乎无法调试它们......

当您不将逻辑中的错误与 GUI 中的错误（刷新/布局/进度条等）混合时，将它们分开会导致代码干净。这种方法还有另一个不错的功能 - 能够在 GUI 人员和逻辑人员之间分担工作，他们可以在没有持续冲突的情况下完成他们的工作。

【讨论】：

【解决方案2】：

正如 Mark 所说，您应该创建一个处理此类事情的新类。

当使用像 wxWidgets 这样的东西时，理想的代码布局是模型视图控制器，其中 wxFrame 类只有显示项目所需的代码，所有逻辑和业务规则都由与 wxFrame 交互的其他类处理。这样您就可以更改逻辑和业务规则，而无需更改您的界面和更改（或交换）您的界面，而无需更改您的逻辑和业务规则。

【讨论】：

【解决方案3】：

我可能从一开始就应该更清楚，但我找到了我要找的东西：

在 wxpython wiki 中，我发现了几个简单、具体的 MVC 项目示例。

【讨论】：

【解决方案4】：

在适当的 OOP 设计中，这将是独立的或文件系统类的一部分 - 它不会是应用程序或框架的一部分。

【讨论】：