我应该在一个文件中放入多少个类?[关闭]

问题:我应该在一个文件中放入多少个类?[关闭]

我习惯了Java模型,每个文件可以有一个公共类。Python没有此限制,我想知道组织类的最佳实践是什么。

I’m used to the Java model where you can have one public class per file. Python doesn’t have this restriction, and I’m wondering what’s the best practice for organizing classes.


回答 0

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 )

将导入视为以概念或大块形式组织代码的方式。每次导入中到底有多少个类并不重要。重要的是您要在import陈述中描绘的整体组织。

A Python file is called a “module” and it’s one way to organize your software so that it makes “sense”. Another is a directory, called a “package”.

A module is a distinct thing that may have one or two dozen closely-related classes. The trick is that a module is something you’ll import, and you need that import to be perfectly sensible to people who will read, maintain and extend your software.

The rule is this: a module is the unit of reuse.

You can’t easily reuse a single class. You should be able to reuse a module without any difficulties. Everything in your library (and everything you download and add) is either a module or a package of modules.

For example, you’re working on something that reads spreadsheets, does some calculations and loads the results into a database. What do you want your main program to look like?

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 )

Think of the import as the way to organize your code in concepts or chunks. Exactly how many classes are in each import doesn’t matter. What matters is the overall organization that you’re portraying with your import statements.


回答 1

由于没有人为的限制,所以它实际上取决于可理解的内容。如果您有一堆在逻辑上分组在一起的相当短,简单的类,则扔一堆’em。如果您有大型,复杂的类或没有整体意义的类,请每个类一个文件。或在两者之间选择。随着情况的变化进行重构。

Since there is no artificial limit, it really depends on what’s comprehensible. If you have a bunch of fairly short, simple classes that are logically grouped together, toss in a bunch of ’em. If you have big, complex classes or classes that don’t make sense as a group, go one file per class. Or pick something in between. Refactor as things change.


回答 2

由于以下原因,我碰巧喜欢Java模型。将每个类放在单独的文件中可通过使类在浏览源代码时更易于查看来促进重用。如果您将一堆类组合到一个文件中,那么对于其他开发人员来说,可能不存在明显的类,这些类可以通过浏览项目的目录结构来重用。因此,如果您认为可以重用您的类,则可以将其放在自己的文件中。

I happen to like the Java model for the following reason. Placing each class in an individual file promotes reuse by making classes easier to see when browsing the source code. If you have a bunch of classes grouped into a single file, it may not be obvious to other developers that there are classes there that can be reused simply by browsing the project’s directory structure. Thus, if you think that your class can possibly be reused, I would put it in its own file.


回答 3

这完全取决于项目的规模,类的时长,是否可以从其他文件中使用它们等等。

例如,我经常使用一系列的类来进行数据抽象-因此我可能有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的模块文件对组织包一些有用的信息。

It entirely depends on how big the project is, how long the classes are, if they will be used from other files and so on.

For example I quite often use a series of classes for data-abstraction – so I may have 4 or 5 classes that may only be 1 line long (class SomeData: pass).

It would be stupid to split each of these into separate files – but since they may be used from different files, putting all these in a separate data_model.py file would make sense, so I can do from mypackage.data_model import SomeData, SomeSubData

If you have a class with lots of code in it, maybe with some functions only it uses, it would be a good idea to split this class and the helper-functions into a separate file.

You should structure them so you do from mypackage.database.schema import MyModel, not from mypackage.email.errors import MyDatabaseModel – if where you are importing things from make sense, and the files aren’t tens of thousands of lines long, you have organised it correctly.

The Python Modules documentation has some useful information on organising packages.


回答 4

当我对文件的庞大性感到厌烦,并且当期望的相关性结构开始自然地出现时,我发现自己将事情分解了。通常这两个阶段似乎是重合的。

如果过早地拆分内容,可能会很烦人,因为您开始意识到需要完全不同的结构排序。

另一方面,当任何.java或.py文件的行数超过700行时,我开始不断地烦恼,试图记住“特定位”在哪里。

使用Python / Jython,import语句的循环依赖关系似乎也发挥了作用:如果您尝试将太多相互协作的基本构件拆分成单独的文件,则这种语言的“限制” /“不完美”似乎会迫使您对事物进行分组,也许以一种明智的方式。

至于拆分成多个程序包,我并不是很清楚,但是我想说的是,烦恼和快乐结构的出现同样的规则适用于所有模块化级别。

I find myself splitting things up when I get annoyed with the bigness of files and when the desirable structure of relatedness starts to emerge naturally. Often these two stages seem to coincide.

It can be very annoying if you split things up too early, because you start to realise that a totally different ordering of structure is required.

On the other hand, when any .java or .py file is getting to more than about 700 lines I start to get annoyed constantly trying to remember where “that particular bit” is.

With Python/Jython circular dependency of import statements also seems to play a role: if you try to split too many cooperating basic building blocks into separate files this “restriction”/”imperfection” of the language seems to force you to group things, perhaps in rather a sensible way.

As to splitting into packages, I don’t really know, but I’d say probably the same rule of annoyance and emergence of happy structure works at all levels of modularity.


回答 5

我要说的是,在该文件中放置尽可能多的类,这些类可以在逻辑上进行分组,而又不会使其变得太大和太复杂。

I would say to put as many classes as can be logically grouped in that file without making it too big and complex.