Question

我知道为什么这是一个坏主意，但这似乎是一个很好的例子，我想知道为什么我错了，我的选择是什么。

我的thing.py充满了核心逻辑。

我有appthing.py想要使用该逻辑，同时为我们使用的环境添加一些特定于应用程序的内容，例如通过我们的应用程序的内置持久存储功能保存有关所述逻辑的用户设置，其中appthing.py会在以后与之交互以恢复状态，等等。

我可以（我认为）：

我不想做1 - 我讨厌重复代码/工作。 2似乎是一个可以使用的熊（appthing.settingA变成了appthing.thing.settingA）。总的来说，3似乎是一个坏主意。这留下了4，import *，我知道这是错误的，但是再次，在这种情况下似乎没问题。

你说什么？我的选择5是什么？感谢。

我应该注意到，任何地方都没有任何课程。我试图打破各地课堂的习惯。这些都不需要它，因此只需在模块之间进行子类化。

Answer 1

5）仅导入您知道将使用的那些功能

6）以面向对象的方式前进并制作thing和appthing个类，其中appthing继承自thing

选择是你的，真的。你认为最好的是什么？特别考虑维护代码的需要。如果thing需要更改某些功能，会发生什么？这对appthing的用户有何影响？

在你的场景中，我可能会选择我自己的选项5.这样就明确了我继承的内容，thing中不会影响appthing的更改可以在不通过代码的情况下完成使用appthing。

我不会选择1号，因为那真的很麻烦。务实，选择一种可以轻松维护的设计。

Answer 2

最好的方法是：

from mymodule.thing import my_settings as settings
#...
# use the name settings everywhere in this client code

这样，如果您的mymodule界面发生变化，您只有一个地方可以更新（DRY原则）。

选项4（from mymodule import *）使您的客户端代码对mymodule中的任何未来更改都很脆弱，并且还会引入名称冲突的机会。如果您确信没有名称冲突，并且您不经常更新“核心”模块，那么它很好;请注意，您的客户端代码存在直接依赖关系。

Answer 3

如果你有一个模块，只提供可以在导入模块中愉快地看到的东西，并且只有一个这样的模块，那么这是可以接受的。

例如，在我的django项目中，我喜欢将models中的所有内容导入views，这会引入我的所有模型，以及其他类，例如django自己的User类不合格的名称进入视图代码。这很方便，因为view模块将始终耦合到models模块。对于任何其他模块，我都不这样做。