每个文件一个类？ [英] One class per file?
问题描述
你好：
这本书代码完整建议你只在一个
源文件中放入一个类，这对我来说似乎有点极端。似乎很多
类都很小，所以把它们中的几个放在一个文件中似乎是合理的。我注意到标准
库中的decimal.py模块有几个类，所有这些当然都围绕着
" decimal"话题。也许更好的经验法则是每个
文件一个想法。我检查了Python样式指南，似乎没有提到这个主题。我知道这是一个基本问题，但是什么
是Python的方式呢？
感谢您的时间。
HCB
Hello:
The book "Code Complete" recommends that you put only one class in a
source file, which seems a bit extreme for me. It seems that many
classes are small, so that putting several of them in a file seems
reasonable. I noticed that the decimal.py module in the standard
library has several classes, all of which of course revolve around the
"decimal" topic. Perhaps a better rule of thumb is "one idea per
file." I checked the Python style guide and there seems to be no
mention of this topic. I know this is an elementary question, but what
is the Python way of doing this?
Thanks for your time.
HCB
推荐答案
HCB< hy ******************* @ gmail.comwrites ：
HCB <hy*******************@gmail.comwrites:
代码完成一书建议你只在一个
源文件中放入一个类，这对我来说似乎有点极端。
The book "Code Complete" recommends that you put only one class in a
source file, which seems a bit extreme for me.
对于Python来说，这是极端的，对于我已经看过的大多数应用程序来说，
会适得其反。哪个版本的Code Complete推荐
这个以及哪个页面？
For Python, that is extreme, and for most applications I''ve seen it
would be counterproductive. Which edition of Code Complete recommends
this, and on which page?
也许更好的经验法则是每个文件一个想法 "我检查了
Python样式指南，似乎没有提到这个主题。我知道这是一个基本问题，但是这样做的后续方法是什么？
这样做？
Perhaps a better rule of thumb is "one idea per file." I checked the
Python style guide and there seems to be no mention of this topic. I
know this is an elementary question, but what is the Python way of
doing this?
你说得对：模块最自然地用于概念
对象的分组（不仅仅是类，而是所有对象） a / b
离散的命名空间区域。
-
\ a ?? WWW令人兴奋因为微软并不拥有它，并且因此，发生了大量的创新|
_o__）。 a ?? Steve Jobs |
Ben Finney
You have it right: modules are most naturally used for conceptual
grouping of objects (not just classes, but all objects) related to a
discrete area of functionality, into a discrete namespace.
--
\ a??The WWW is exciting because Microsoft doesn''t own it, and |
`\ therefore, there''s a tremendous amount of innovation |
_o__) happening.a?? a??Steve Jobs |
Ben Finney
2008年9月29日星期一06:12:35 -0700，HCB写道：
On Mon, 29 Sep 2008 06:12:35 -0700, HCB wrote:
你好：
这本书代码完整建议你只在一个
源文件中放入一个类，这对我来说似乎有点极端。似乎很多
类都很小，所以把它们中的几个放在一个文件中似乎是合理的。我注意到标准库中的decimal.py模块
有几个类，所有这些当然都围绕着十进制
主题。也许更好的经验法则是每个文件一个想法。我查了一下Python样式指南的
，似乎没有提到这个主题。我知道这是一个基本的问题，但是这样做的Python方式是什么？这需要什么？
感谢你的时间。
HCB
Hello:
The book "Code Complete" recommends that you put only one class in a
source file, which seems a bit extreme for me. It seems that many
classes are small, so that putting several of them in a file seems
reasonable. I noticed that the decimal.py module in the standard library
has several classes, all of which of course revolve around the "decimal"
topic. Perhaps a better rule of thumb is "one idea per file." I checked
the Python style guide and there seems to be no mention of this topic. I
know this is an elementary question, but what is the Python way of doing
this?
Thanks for your time.
HCB
这听起来很糟糕！想象一下，要编辑一百万个源文件，每次进行更改时，都要重新命名，创建，删除
。当然，每个Java粉丝
都可以给你一百万个理由，否则宇宙会崩溃，
但这在python中是完全不切实际的。如果合理使用，Python的模块组织
和命名空间就足够了。
That sounds terrible! Imagine having a million source files to edit,
rename, create, delete each time you make a change. Sure, every Java fan
can give you a million reasons why the universe will collapse otherwise,
but this is totally impractical in python. Python''s module organization
and namespaces are more than enough if used reasonably.
代码完整一书建议你只在一个
源文件中放入一个类，这对我来说似乎有点极端。似乎很多
类都很小，所以把它们中的几个放在一个文件中似乎是合理的。我注意到标准
库中的decimal.py模块有几个类，所有这些当然都围绕着
" decimal"话题。也许更好的经验法则是每个
文件一个想法。我检查了Python样式指南，似乎没有提到这个主题。我知道这是一个基本问题，但是什么
是这样做的Python方式？
The book "Code Complete" recommends that you put only one class in a
source file, which seems a bit extreme for me. It seems that many
classes are small, so that putting several of them in a file seems
reasonable. I noticed that the decimal.py module in the standard
library has several classes, all of which of course revolve around the
"decimal" topic. Perhaps a better rule of thumb is "one idea per
file." I checked the Python style guide and there seems to be no
mention of this topic. I know this is an elementary question, but what
is the Python way of doing this?
我处于类似情况。我一直在阅读Robert C. Martins的书。
敏捷软件开发他提出了类似的建议。我会强烈推荐这本书。他还有一些关于打包的章节，他在这个章节中提出了一些关于
推理的非常好的观点。基本上你想要在
中组织你的代码，使得包依赖性朝着增加稳定性的方向移动。在这种情况下，稳定性是一个指标，它被定义为代码将来发生变化的可能性，因为
取决于它依赖于多少包而不是它取决于多少
包。他描绘了几个场景，他将
组合在一起打包_seem_相关，只是为了看到
导致他所有的包需要重新每次需要更改
时都会构建。显然我们不需要重新构建python代码，
但是以这样的方式组织你的代码仍然很有用
没有不断重新访问代码集。
我实际上已经开始使用他的建议并且每个文件都放了一个
类。当一个类依赖于另一个类时，我将其包含在
来自x import X中。这使得很容易确定
依赖关系（好吧，非抽象依赖关系，接口
是一个不同的故事*）。然后我将所有课程放在一个
包中，然后制作公共课程。在包级别可见的类通过
将它们导入包__init__模块。
据说，如果我创建了一个_only_使用的类一个
其他单班，显然它永远不会被制作
在该文件之外可见，我肯定会把它放在同一个
文件作为该类。哎呀，你甚至可以重构你的代码和
当时确定某些代码只用了一个
其他一块。事实上将代码放在一起比将它分开要容易得多，尤其是在游戏后期。
我的建议：不要''敲它直到你尝试它。我认为自从采纳这个建议后，我的代码已经有了很大的改进。在开发周期的后期很难确定哪些类要打包在一起直到很多
，这可能会更加困难。有一点可以帮到找到一个
IDE，可以帮助您轻松切换文件。我使用WingIDE，但是
我甚至使用带有标签文件的vim，这并不可怕。我不会说这是一个很难的规则，但与此同时我不会只是忽略它。试一试并调整您的开发技巧，看看
什么最适合您。
示例：
[mypackage / __ init__.py]
__all__ = [" X"]
来自.x import X
[结束mypackage / __ init__.py]
[mypackage / x.py]
来自.y import的
Y
__all__ = [" X"]
class X（对象）：
＃code - 希望使用Y
[结束mypackage / x.py]
[mypackage / y.py]
__all__ = [" Y"]
class Y（对象）：
＃code
[end mypackage / y.py]
Matt
* python中的接口表示隐式依赖项。
Python的禅宗说：明确比隐含更好。我计划在python 2.6 / 3.0中使用ABC模块实验
。我想明确定义我的
接口，但另一方面我仍然希望它对于使用我的代码的人来说很容易使用
。这个_seems_可能是
因为你可以在它之后注册一个带有接口的类
已经被创建了，但是我不确定它是非常pythonic的
每次使用时都会显式检查接口。然而，将接口导入到一个文件中并且只是为了记录依赖关系而明确使用
，这似乎很傻。如果有人有b
指针让我知道。
I''m in a similar situation. I''ve been reading Robert C. Martins book
"Agile Software Development" and he suggests something similar. I
would highly recommend that book by the way. He also has a couple of
chapters on packaging where he makes some very good points about the
reasoning behind it. Basically that you want to organize your code in
such a way that package dependencies move in the direction of
increasing stability. In this case stability is a metric which is
defined as how likely the code is going to change in the future as
determined by how many packages depend on it as opposed to how many
packages it depends on. He paints a couple of scenarios in which he
groups packages together that _seem_ to be related, only to see that
it results in all of his packages needing to be re-built every time a
change is required. Obviously we don''t have to re-build python code,
but it is still useful to organize your code in such a way that you
don''t have to constantly re-visit collections of code.
I have actually started using his suggestion and have been putting one
class per file. When one class depends on another I include it with a
"from x import X". This makes it very easy to determine the
dependencies (well, the non-abstract dependencies anyway, interfaces
are a different story*). Then I put all of my classes together in a
package, and make the "public" classes visible on a package level by
importing them into the package __init__ module.
With that being said, If I made a class that was _only_ used by one
other single class, and it was clear that it would never be made
visible outside of that file, I would certainly put it in the same
file as that class. Heck, you might even refactor your code and
determine at that time that some piece of code is only used by one
other piece. It is much easier to put code together after the fact
than it is to separate it, especially later in the game.
My advice: don''t knock it until you try it. I think my code has
improved quite a bit since taking this advice. It can be much more
difficult to determine which classes to package together until much
later in the development cycle. One thing that can help is to find an
IDE that helps you to easily switch between files. I use WingIDE, but
I have even used vim with a tags file and it wasn''t terrible. I
wouldn''t call it a hard rule, but at the same time I wouldn''t just
ignore it. Give it a shot and adapt your development technique to see
what works best for you.
Example:
[mypackage/__init__.py]
__all__ = ["X"]
from .x import X
[end mypackage/__init__.py]
[mypackage/x.py]
from .y import Y
__all__ = ["X"]
class X(object):
# code - using Y hopefully
[end mypackage/x.py]
[mypackage/y.py]
__all__ = ["Y"]
class Y(object):
# code
[end mypackage/y.py]
Matt
* Interfaces in python represent an implicit dependency. The Zen of
Python states: "Explicit is better than implicit". I plan to
experiment with the ABC module in python 2.6/3.0. I want to make my
interfaces explicitly defined, but on the other hand I still want it
to be easy for people who use my code to duck-type. This _seems_ to be
possible since you can .register a class with an interface after it
has been created, but I''m not sure that it is very pythonic to
explicitly check for an interface every time it is used. It would seem
silly however to import an interface into a file where it isn''t
explicitly used just to document the dependency. If anybody has
pointers let me know.
这篇关于每个文件一个类？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
