我应该在一个文件中放入多less个Python类？
我习惯于Java模型，每个文件可以有一个公共类。 Python没有这个限制，我想知道组织类的最佳做法是什么。
一个Python文件被称为“模块”，它是组织软件的一种方式，使其变得“有意义”。 另一个是名为“包”的目录。
一个模块是一个独特的东西，可能有一两个紧密相关的类。 诀窍是一个模块是你要导入的东西，你需要这个导入对于那些会读取，维护和扩展你的软件的人来说是非常明智的。
规则是这样的： 一个模块是重用的单位 。
你不能轻松地重用一个类。 您应该能够毫无困难地重用模块。 库中的所有内容（以及下载和添加的所有内容）可以是模块，也可以是一个模块包。
例如，您正在研究读取电子表格的内容，进行一些计算并将结果加载到数据库中。 你想让你的主程序看起来像什么？
from ssReader import Reader from theCalcs import ACalc, AnotherCalc from theDB import Loader def main( sourceFileName ): rdr= Reader( sourceFileName ) c1= ACalc( options ) c2= AnotherCalc( options ) ldr= Loader( parameters ) for myObj in rdr.readAll(): c1.thisOp( myObj ) c2.thatOp( myObj ) ldr.laod( myObj ) 将导入视为在概念或块中组织代码的方式。 在每个导入中究竟有多less类并不重要。 重要的是你用import报表描绘的整个组织。
既然没有人为的限制，那真的取决于什么是可理解的。 如果你有一堆相当短暂，简单的逻辑分类的类，就把它们扔在一堆。 如果你有一些大而复杂的class级或class级，那么每个class级只能有一个档案。 或者在中间挑选一些东西。 随着事物的改变重构。
这完全取决于项目有多大，类是多长，如果从其他文件使用等等。
例如，我经常使用一系列的数据抽象类 – 所以我可能有4或5类，可能只有1行（ class SomeData: pass ）。
这将是愚蠢的分裂成单独的文件中的每一个 – 但是，因为他们可能会使用不同的文件，把所有这些在一个单独的data_model.py文件是有道理的，所以我可以from mypackage.data_model import SomeData, SomeSubData
如果你有一个有很多代码的类，也许只有它使用的一些函数，将这个类和辅助函数分解成一个单独的文件是一个好主意。
你应该from mypackage.database.schema import MyModel ，而不是from mypackage.email.errors import MyDatabaseModel – 如果你从那里导入东西，而且这些文件不是成千上万行，已经正确组织它。
Python模块文档有关于组织软件包的一些有用的信息。
我碰巧喜欢Java模型的原因如下。 将每个类放在一个单独的文件中，可以在浏览源代码时更容易看到类，从而促进重用。 如果将一大堆类组合到一个文件中，那么其他开发人员可能并不清楚那里有哪些类可以通过浏览项目的目录结构来重用。 因此，如果你认为你的课堂可以被重用，我会把它放在自己的档案中。
当我厌恶文件的庞大性，以及相关性的理想结构开始自然出现时，我发现自己在分裂事物。 通常这两个阶段似乎是一致的。
如果你把事情分解得太早，会非常烦人，因为你开始意识到需要完全不同的结构sorting。
另一方面，当任何.java或.py文件超过700行时，我开始不停地试图记住“那个特定位”在哪里。
使用Python / Jython导入语句的循环依赖似乎也起到了一定的作用：如果你试图将太多合作的基本构build块拆分成单独的文件，这种语言的“限制”/“不完美”似乎迫使你对事物进行分组，相当明智的方式。
至于分裂成包，我真的不知道，但我可能会说，模块化的各个层面上，快乐结构工程的烦恼和出现可能是相同的规则。
我想说的是把尽可能多的类放在那个逻辑上分组的文件中，而不要把它放得太大又复杂。
