代码之家 › 专栏 › 技术社区 › bouvard

如何连贯地组织PyGTK桌面应用程序的模块?

organization pygtk module gtk python

bouvard · 技术社区 · 16 年前

我正在Pygtk的一个桌面应用程序上工作,似乎遇到了我的文件组织的一些限制。到目前为止,我的项目结构如下:

application.py-保存主应用程序类(大多数函数例程)
py-包含一个松散耦合的GTK GUI实现。处理信号回调等。
command.py-保留不依赖于应用程序类中数据的命令行自动化函数
state.py-保存状态数据持久性类

到目前为止,这已经相当不错了,但此时application.py开始变得相当长。我看过许多其他的Pygtk应用程序,它们似乎有类似的结构问题。在某一点上,主模块开始变得非常长,没有明显的方法可以在不牺牲清晰性和对象方向的情况下将代码分解为更窄的模块。

我曾考虑过将GUI作为主要模块,并为工具栏例程、菜单例程等提供单独的模块,但在这一点上,我相信我将失去OOP的大部分好处,最终得到一个“一切都引用一切”的场景。

我应该只处理一个非常长的中央模块,还是有更好的方法来构建项目,这样我就不必太依赖类浏览器了?

编辑I

好吧,关于MVC的所有东西都有点问题。我的代码中确实有一个MVC的粗略近似值,但不可否认,通过进一步分离模型和控制器,我可能会获得一些里程数。但是,我正在阅读python gtkmvc的文档(顺便说一下,这是一个很好的发现,谢谢您参考它),我的印象是,它不会解决我的问题,而只是形式化它。我的应用程序是一个glade文件,通常是一个窗口。因此,无论我如何严格地定义模块的MVC角色,我仍然会让一个控制器模块做大多数事情,这几乎就是我现在所拥有的。诚然,我对适当的MVC实现有点模糊,我将继续研究,但在我看来,这种架构不会从我的主文件中得到更多的东西,它只会将该文件重命名为controller.py。

我应该为窗口的单独部分(工具栏、菜单等)考虑单独的控制器/视图对吗?也许这就是我在这里所缺少的。看来这就是洛特在第二个要点中所指的。

感谢迄今为止的回应。

6 回复 | 直到 16 年前

Jaime Soriano 16 年前

项目中 Wader 我们使用 python gtkmvc ,这使得在使用pygtk和glade时更容易应用MVC模式,您可以在 svn repository :

wader/
  cli/
  common/
  contrib/
  gtk/
    controllers/
    models/
    views/
  test/
  utils/

JesperE 16 年前

这可能与Pygtk无关,而是一个通用的代码组织问题。您可能会受益于应用一些MVC(模型-视图-控制器)设计模式。见 Design Patterns 例如。

S.Lott 16 年前

“保留主应用程序类(大多数函数例程)”

就像单数一样——一个班?

我并不惊讶 一个班什么都做 设计不起作用。它可能不是我所说的面向对象的。如果您的功能堆积在一个类中,听起来不像是遵循典型的MVC设计模式。

这堂课上有什么?我建议您可以将其重构为片段。对于重构应用程序类,您有两个候选维度——如果我真的猜对了,您已经将所有内容都放到了一个类中。

在做任何其他事情之前,重构为与现实世界实体并行的组件。目前还不清楚“state.py”中的内容——这是否是一个真实实体的适当模型,或者只是持久存储和应用程序中某些模糊数据结构之间的映射。很可能您会将处理从应用程序转移到模型中(可能是state.py,也可能是一个适当模型的新模块)。

把你的模型拆成碎片。它将帮助组织控件和视图元素。最常见的MVC错误是控制太多,模型中没有任何内容。
稍后,一旦您的模型完成了大部分工作,您可以查看重构到与GUI表示并行的组件中。例如,各种顶层框架可能都应该有单独的控件对象。现在还不清楚“gui.py”中的内容——这可能是一个合适的视图。似乎缺少的是一个控制组件。

Ali Afshar 16 年前

很抱歉这么晚回答。 Kiwi 在我看来,这是一个比GTKMVC更好的解决方案。这是我对任何Pygtk项目的第一个依赖。

gimel 16 年前

python 2.6支持 explicit relative imports 这使得使用包比以前的版本更容易。我建议你把你的应用程序分解成一个包内的小模块。您可以这样组织应用程序:

myapp/
  application/
  gui/
  command/
  state/

每个目录都有自己的目录 __init__.py . 您可以查看任何Python应用程序甚至标准库模块,以获取示例。

bouvard 16 年前

因此,在没有听到我对原始问题的修改之后,我做了更多的研究,我的结论是对 ,我应该将接口分成几个视图,每个视图都有自己的控制器。python gtkmvc通过提供 glade_top_widget_name 视图构造函数的参数。这一切似乎都很有意义,尽管这将需要对我现有的代码库进行大范围的重构,而我可能愿意或不愿意在短期内(我知道,我知道,我应该此外,我还想知道是否应该只拥有一个模型对象(我的应用程序相当简单——不超过25个状态变量),或者是否应该将其分解为多个模型,并处理观察多个模型的控制器,并在它们之间链接通知。(再说一遍,我知道我真的应该如果有人有更深入的见解,我仍然不觉得我已经得到了原始问题的答案,尽管我现在有一个方向要走。

(而且,它们似乎应该是手头上的其他体系结构选择,尽管到目前为止,我还没有看到用MVC样式编码的单个Python应用程序,但是许多Python应用程序都有我上面描述的确切问题。)