在阅读python文档和各种邮件列表时，我总是阅读看起来有点像教条的内容。全局变量应该尽量避免，它们是糟糕的设计……好的，为什么不呢?但是在现实生活中有一些情况下，我不知道如何避免这样的模式。
假设我有一个GUI，可以从主菜单加载几个文件。与加载文件相对应的文件对象可以在所有GUI中使用(例如，将显示图像的图像查看器，可以通过不同的对话框/插件在其上执行各种操作)。
构建以下设计真的有问题吗?
- Menu.py——>文件将从这里加载
- Main.py——>加载的文件对象可以在这里使用
- Dialog1.py -->或此处
- Dialog2.py ->或there
- Dialog3.py ->或there
- …
- Globals.py
，其中global .py将存储一个字典，其键是加载文件的名称，值是相应的文件对象。然后，从那里，需要这些数据的代码的各个部分将通过弱引用访问它。
如果我的问题看起来(或者是)愚蠢，对不起，但是你看到任何优雅的或无全局的替代方案吗?一种方法是将加载的数据字典封装在main .py的主应用程序类中，将其视为GUI的中心访问部分。然而，这也会带来一些复杂性，因为这个类应该可以很容易地从需要数据的所有对话框中访问，即使它们是它的直接子类。
谢谢你的帮助
应该避免使用全局变量，因为它们会抑制代码重用。多个小部件/应用程序可以很好地驻留在同一个主循环中。这允许您将您现在认为的单个GUI抽象到一个库中，该库根据请求创建这样的GUI，因此(例如)单个启动器可以启动共享同一进程的多个顶级GUI。
如果您使用全局变量，这是不可能的，因为多个GUI实例将压倒彼此的状态。
替代全局变量的方法是将所需的属性与顶级小部件关联起来，并创建指向相同顶级小部件的子小部件。然后，例如，菜单操作将使用其顶级小部件到达当前打开的文件，以便对其进行操作。
我将通过将数据封装在一个或多个类中并为这些类实现borg模式来管理全局数据。参见为什么Borg模式比Python中的Singleton模式更好