每个包有多少班？每班的方法？每种方法的线？

Question

我必须对一些巨大的Java项目给出一般性的说明，但我很少见，而且我想知道是否有任何确定的指导原则：

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

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

Answer 1

史蒂夫麦康奈尔在他的书“代码完成”中推荐每个类约7种方法，然后在一个方法中不再有行可以在不滚动的情况下在单个屏幕中查看。

我不确定每个包的类。

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

Answer 2

我认为这样的统计数据非常无用，知道每个方法的行数如何表明它对项目是否有用;我认为你应该更多地看待：

1. 你的包裹是否包含 类？
2. 你的课程是否有效 实体自己？
3. 做方法 在类函数内 正确有效吗？

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

Answer 3

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

在杰夫·贝（Jeff Bay）的文章“对象健美操”（Object Calisthenics）中，“思想工具集”（ThoughtWorks Anthology）一书中也有一个很好的观点。他建议9个非常严格的约束条件，从长远来看，这将使你成为一个更好的OO开发者。 Read more about them here.

要回答您的具体问题，这些是您特别要求的限制： - 每个包不超过10个班级 - 每班最多50行

这些约束可能并不适用于所有真实项目，但在小型（爱好？）项目中使用它们会迫使您进行更好的练习。

Answer 4

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

3.89班/包非常低。这意味着你将在一个复杂的包树丛中战斗。

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

Answer 5

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

对于方法，您可以采用类似的视图，并针对尽可能小但不小的方法。可以这样想：如果你可以将方法分成两个或多个不同的部分，那么它显然不会像它那样小。小方法很容易理解，通过分割这样的代码，您将在高级方法中获得更好的概述，并将细节推送到低级方法。

Answer 6

（注意：tl; dr可以在最底层找到我真实的意见）

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

我个人喜欢将一个访问级别的所有方法保存在一个类中，这意味着一些实用程序类可能最终会有数百种方法，但在我看来，StringUtil.escapeXMLspecialCharacters(someString)比StringUtil.XML.escapeSpecialCharacters(someString)更容易。 }或XMLUtil.escapeSpecialCharacters(someString)。虽然这些都是看似不错的解决方案，但第一个解决方案是蓬勃发展的（至少在我看来，就是这样！）因为访问该方法很简单，也很简单：你不必考虑你正在处理的字符串是否包含XML或XHTML或JSON或其他什么，您只需从一般方法组中选择一种方法，就是这样。

保持以前的电视遥控器类比，让我们假设您无论如何都要将它们分成不同的类别。如果我们允许自己平均每个类有7个这样的方法，并设法将遥控器上的按钮分组到MenuButtons，AdjustmentButtons和'NumberSelectorButtons'等感性组，我们最终得到8个左右类。这实际上并不是一件坏事，但它会轻易引起混淆，特别是如果他们没有非常谨慎地分配给敏感的团体。想象一下你的TVRemotes'R'Us Inc.办公室周围的咆哮：“谁说电源开/关按钮是一个控制按钮？” “谁是将音量+/-放到菜单按钮上的小丑？PRE / CH （在当前和上一个频道和/或图像源之间切换的按钮）按钮不是数字按钮！” “指南按钮打开电视指南和导航菜单，具体取决于背景，我们将用它做什么！？”

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

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

这是 TL; DR ：

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

• 包foo包含用于实现的接口和其他常用类。
• 包foo.bar包含函数bar
的所述接口的实现
• 包foo.baz包含函数baz
的所述接口的实现

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

每个类的方法：如上所述，所有这些都是必需的。如果你的班级不能没有170种方法，那就让它拥有它们。重构是一种美德，而不是一直可以应用的东西。

每种方法的线数：尽可能低，我通常每种方法最终得到10到25行，而25对我来说有点高，所以我认为10是一个很好的平衡点。