Java 每个包有多少个类？每个类的方法？每个方法的行？

how many classes per package? methods per class? lines per method?

提问by karlipoppins

I have to give a general note to some huge Java project for which I have but little visibility and I was wondering if there were any guidelines for determining:

我必须对一些我几乎看不到的大型 Java 项目进行一般性说明，我想知道是否有任何指导方针来确定：

• what number of classes per package can be considered right, to low, or to high (this project has 3.89 classes per package, which seems a bit too small for me),
• number of methods per class? (this project has 6.54 methods per class...
• number of lines per method? (this project has about 7 lines per method (seems pretty good to me, maybe a bit low))

• 每个包有多少类可以被认为是正确的、低的或高的（这个项目每个包有 3.89 个类，这对我来说似乎有点太少了），
• 每个类的方法数？（这个项目每个类有 6.54 个方法......
• 每个方法的行数？（这个项目每个方法大约有 7 行（对我来说似乎很好，可能有点低））

I should note that this question is only dealing with volumetry. I have a bunch of reports from quality tools (checkstyle, jdepend, cpd, pmd, ncss) that give me more vision about code redundancy, classes usage, bugs, etc.

我应该注意到这个问题只涉及体积测量。我有一堆来自质量工具（checkstyle、jdepend、cpd、pmd、ncss）的报告，它们让我对代码冗余、类使用、错误等有了更多的了解。

采纳答案by Yona

Steve McConnell in his book Code Complete recommends about 7 methods per class and no more lines in a method then can be viewed in a single screen without scrolling.

Steve McConnell 在他的 Code Complete 一书中建议每个类使用大约 7 个方法，并且一个方法中没有更多行可以在单个屏幕中查看而无需滚动。

I'm not sure about classes per package.

我不确定每个包的类。

I would highly recommend reading Code Complete for more information on such topics.

我强烈建议阅读 Code Complete 以获取有关此类主题的更多信息。

回答by Mauro

I think stats like that are pretty useless, how does knowing the lines per method show whether its any use to the project or not; i think you should be looking more along the lines of:

我认为这样的统计数据非常无用，知道每个方法的行如何显示它是否对项目有用？我认为您应该更多地关注以下方面：

1. Do your packages encompass like classes?
2. Do your classes work as an entity on their own?
3. Do the methods within the classes function correctly and efficiently?

1. 你的包是否包含类？
2. 你的班级是否作为一个实体独立运作？
3. 类中的方法是否正确有效地运行？

Surely other than memory usage, it doesn't matter whether the method is large or not? the other thing to look for in very protracted methods is whether the stack trace is going to be bigger than adding that functionality to a parent method. I'd be wary of measuring a projects success based on the lines of code.

当然除了内存使用之外，方法是否大都没有关系？在非常长的方法中寻找的另一件事是堆栈跟踪是否会比将该功能添加到父方法更大。我会谨慎地根据代码行来衡量项目的成功。

回答by Itay Maman

Unfortunately, there's no absolute (objective) notion of quality in software. Thus, there's no "right" value for these. However, here are a two (personal) obsevations:

不幸的是，软件中没有绝对（客观）的质量概念。因此，这些没有“正确”的价值。但是，这里有两个（个人）观察：

3.89 classes/package is very low. It means you'll be battling through a complicated tree of packages.

3.89 个类/包非常低。这意味着您将与复杂的包树作斗争。

7 Lines per method: Indeed sounds good. However, if these number was arrived at as a result of an intentional effort to reduce the line count of methods then you might have ended up with a single logical task being spread around several private methods which will make it more difficult to understand the class (in certain cases). Actually in CodeComplete-2, the author cites a research which discovered that method length is much less importance than its cyclomatic complexity and its nesting level.

每个方法 7 行：确实听起来不错。但是，如果这些数字是由于有意减少方法的行数而获得的，那么您最终可能会得到一个单一的逻辑任务，该任务分布在多个私有方法中，这将使理解类变得更加困难（在某些情况下）。实际上，在 CodeComplete-2 中，作者引用了一项研究，该研究发现方法长度远不如其圈复杂度和嵌套级别重要。

回答by Peter Evjan

Robert C. Martin, who recently released the book "Clean Code", states that the number of lines per method should be the absolutely smallest possible. Between 1-7 lines is a good rule of thumb.

最近出版了“清洁代码”一书的 Robert C. Martin 指出，每个方法的行数应该是绝对最小的。1-7 行之间是一个很好的经验法则。

There's also a good point being made in the book The ThoughtWorks Anthology, in the essay “Object Calisthenics” by Jeff Bay. He suggests 9 pretty hardcore constraints that will make you a better OO developer in the long run. Read more about them here.

在 The ThoughtWorks Anthology 一书中，Jeff Bay 的文章“Object Calisthenics”中也提出了一个很好的观点。他建议了 9 个非常核心的约束，从长远来看，它们将使您成为更好的 OO 开发人员。在此处阅读有关它们的更多信息。

To answer your specific questions, these are the constraints specifically to you: - No more than 10 classes per package - A maximum of 50 lines per class

为了回答您的具体问题，以下是专门针对您的限制条件： - 每个包裹不超过 10 个课程 - 每个课程最多 50 行

These constraints might not be ideal for all of your real projects, but using them in a small (hobby?) project will force you into a better practice.

这些约束对于您的所有实际项目可能并不理想，但在小型（爱好？）项目中使用它们将迫使您进行更好的实践。

回答by Brian Rasmussen

A useful design guideline says that each class should only do one thing and do it well. This will not give you a fixed number of methods per class, but it will limit the number and make the class easier to comprehend and maintain.

一个有用的设计指南说，每个类应该只做一件事并做好。这不会为每个类提供固定数量的方法，但它会限制数量并使类更易于理解和维护。

For methods you can adopt a similar view and aim for methods that are as small as possible, but no smaller. Think of it this way: if you can split the method into two or more distinct parts it is obviously not as small as it could be. Small methods are easy to understand and by splitting the code like this you will get a better overview in high level methods and push details to low level methods.

对于方法，您可以采用类似的观点，并以尽可能小的方法为目标，但不能更小。可以这样想：如果您可以将方法拆分为两个或多个不同的部分，那么它显然不会小到应有的程度。小方法很容易理解，通过像这样拆分代码，您将更好地了解高级方法并将细节推送到低级方法。

回答by P Arrayah

(note: tl;dr available at the very bottom for my real opinion)

（注意：tl;dr 可在最底部获得我的真实意见）

I'm not going to quote any big name and say that's the right answer because it's always very case dependant how you do all this stuff. For example the number of methods: If you're making a control software for modern HD LCD TV's remote controller which has about 40-50 buttons, how can you break that down into classes coherentlyso that you only have like, say, 7 methods per class?

我不会引用任何知名人士并说这是正确的答案，因为这总是非常依赖于你如何做所有这些事情。例如方法的数量：如果你正在为现代高清液晶电视的遥控器制作一个控制软件，它有大约 40-50 个按钮，你怎么能把它连贯地分解成类，这样你就只有 7 种方法每班？

Personally I like to keep all the methods of one accessor level in one class which means some utility classes may end up having hundreds of methods but in my opinions it's easier to do something like StringUtil.escapeXMLspecialCharacters(someString)than StringUtil.XML.escapeSpecialCharacters(someString)or XMLUtil.escapeSpecialCharacters(someString). While these all are seemingly OK solutions, the first one thrives (at least in my mind, that is!) because it's simple and very easy way to access that method: You don't have to think if the string you're handling contains XML or XHTML or JSON or whatever, you'll just pick one method from the general group of methods and that's it.

我个人想保持一个访问级别的所有方法中的一类，这意味着一些实用类最终可能有数以百计的方法，但在我的意见很容易这样做StringUtil.escapeXMLspecialCharacters(someString)比StringUtil.XML.escapeSpecialCharacters(someString)或XMLUtil.escapeSpecialCharacters(someString)。虽然这些似乎都是不错的解决方案，但第一个解决方案很受欢迎（至少在我看来，就是这样！）因为它是访问该方法的简单且非常容易的方法：您不必考虑您正在处理的字符串是否包含XML 或 XHTML 或 JSON 或其他任何内容，您只需从一般方法组中选择一种方法即可。

Keeping on the previous TV remote analogy, lets assume you do split them to various classes anyway. If we allow ourselves to have 7 of such methods per class on average and manage to group the buttons on the remote to sensical groups like MenuButtons, AdjustmentButtonsand 'NumberSelectorButtons', we end up with 8 or so classes. That's not a bad thing actually, but it gets slightly confusing easily especially if they're not divided to sensical groups with great care. Just imagine the rants around your TVRemotes'R'Us Inc. office: "Who says the power on/off button is a control button?" "Who's the joker who put volume +/- to menu buttons? PRE/CH (the button which switches between current and previous channel and/or image source)button isn't a number button!" "The guide button opens both tv guide AND navigational menu depending on context, what are we going to do with it!?"

继续前面的电视遥控器类比，假设您确实将它们分成了不同的类。如果我们允许自己平均每个类有 7 个这样的方法，并设法将遥控器上的按钮分组到有意义的组，如MenuButtons,AdjustmentButtons和 'NumberSelectorButtons'，我们最终会得到 8 个左右的类。这实际上并不是一件坏事，但它很容易让人有点困惑，尤其是如果他们没有非常小心地划分为敏感的群体。想象一下您 TVRemotes'R'Us Inc. 办公室周围的咆哮：“谁说电源开/关按钮是控制按钮？” “谁是将音量 +/- 放在菜单按钮上的小丑？PRE/CH （在当前和上一个频道和/或图像源之间切换的按钮）按钮不是数字按钮！” “指南按钮根据上下文同时打开电视指南和导航菜单，我们将用它做什么！？”

So as you can hopefully see from this example, using some arbitrary number to limit yourself could introduce some unneeded complexity and break the logical flow of the application.

因此，正如您希望从这个示例中看到的那样，使用任意数字来限制自己可能会引入一些不必要的复杂性并破坏应用程序的逻辑流程。

Before I throw in my last two cents, one thing about the number of lines per method: Think code as blocks. Each loop is a block, each conditional is a block and so on and so forth. What is the minimum amount of these blocks needed for a unit of code which has a single responsibility? That should be your limiter, not the desire to have "Seven everywhere." from number of classes in package, methods in classes and lines of code in methods.

在我投入最后两分钱之前，关于每个方法的行数的一件事是：将代码视为块。每个循环都是一个块，每个条件都是一个块，依此类推。具有单一职责的代码单元所需的这些块的最少数量是多少？那应该是你的限制因素，而不是“到处都有七个”的愿望。从包中的类数、类中的方法和方法中的代码行数。

And here's the TL;DR:

这是TL;DR：

So, my real opinion is actually this: The number of classes in package should be fairly low. I've been lately starting to do the following but I'm not sure if I'll keep up to it:

所以，我的真实想法实际上是这样的：包中的类数量应该相当少。我最近开始做以下事情，但我不确定我是否会跟上它：

• Package foocontains interfaces and other common classes for implementations.
• Package foo.barcontains implementation of said interfaces for function bar
• Package foo.bazcontains implementation of said interfaces for function baz

• 包foo包含用于实现的接口和其他常见类。
• 包foo.bar包含上述功能接口的实现bar
• 包foo.baz包含上述功能接口的实现baz

This usually means my whole structure has a coherent (and most likely low) number of classes and by reading the top level class interfaces (and their comments) I should be able to understand the other packages too.

这通常意味着我的整个结构具有连贯的（并且很可能很少）数量的类，并且通过阅读顶级类接口（及其注释），我也应该能够理解其他包。

Methods per class: All which are needed as I explained above. If your class can't live without 170 methods, then let it have them. Refactoring is a virtue, not something that can be applied all the time.

每个类的方法：正如我上面解释的那样，所有这些都是需要的。如果你的班级没有 170 个方法就活不下去，那就让它拥有它们。重构是一种美德，不是可以一直应用的东西。

Lines per method: As low as possible, I usually end up with 10 to 25 lines per method and 25 is a bit high for me so I'd say 10 is a good balance point for that.

每个方法的行数：越低越好，我通常每个方法有 10 到 25 行，而 25 对我来说有点高，所以我认为 10 是一个很好的平衡点。