我从 wxPython 开始，并且一直在努力完成我可以掌握的每一个教程和示例。然而，我遇到了一个小问题，它与 wx.App 与 wx.Frame 有关，并且应该包含特定的方法。几乎我见过的每个示例都没有超出布局/大小调整和事件处理，没有一个真正解决 wxPython 项目的项目组织。
例如，我有一个获取文件夹列表的方法。大多数示例处理此问题的方式是将方法直接粘贴在框架类中。此方法有可能在应用程序的其他几个部分中使用，因此将其存储在应用程序类级别会更有意义。
我应该如何组织和调用这样的“通用”方法，以免我的框架类混乱。
更新：
为了澄清，“文件夹列表”只是一个例子，我的实际方法做了更多的工作。我要说的是我的代码不是特定于框架的。如果我在应用程序类中有这个，那么从我的框架中的事件方法和事件方法中调用它的最佳方法是什么。
我正在寻找实际的项目组织技术，而不是编程基础。
正如马克所说，你应该创建一个新的类来处理这样的事情。
使用 wxWidgets 之类的代码时，理想的代码布局是模型视图控制器，其中 wxFrame 类只有显示项目所需的代码，所有逻辑和业务规则都由与 wxFrame 交互的其他类处理。通过这种方式，您可以更改逻辑和业务规则，而无需更改您的界面和更改（或交换）您的界面，而无需更改您的逻辑和业务规则。
从 wxWidgets/wxPython 数据类型继承的类不应实现任何业务逻辑。wxWidgets 是一个 GUI 库，因此 wxApp 或 wxFrame 的任何子类都应该专注于 GUI，即显示界面和响应用户操作。
有用的代码应该从 wx 中分离出来，因为您可以稍后决定在某些 Web 或控制台应用程序中使用它，并且您不想在这种情况下创建 wxApp 对象。您还可以稍后决定将一些计算移动到单独的“工作线程”，而您的 GUI 将成为“主线程” - 响应式，并在长期计算期间正确重新绘制。
最后但并非最不重要的一点 - 封装逻辑的类可能会在项目生命周期内增长。如果它们与您的 GUI 类混合在一起，它们会增长得更快，最后它们变得如此复杂以至于您几乎无法调试它们......
当您不将逻辑中的错误与 GUI 中的错误（刷新/布局/进度条等）混合时，将它们分开会导致干净的代码。这种方法还有另一个很好的特性——能够在 GUI 人员和逻辑人员之间拆分工作，他们可以在没有持续冲突的情况下完成他们的工作。
我可能从一开始就应该更清楚，但我找到了我要找的东西：
http://wiki.wxpython.org/ModelViewController/
在 wxpython wiki 中，我发现了几个简单、具体的 MVC 项目示例。
在适当的 OOP 设计中，这将是独立的或文件系统类的一部分 - 它不会是应用程序或框架的一部分。