java - 即使是很小的任务也可以制定这么多方法吗？

Question

我想知道许多开发人员都做同样的事情来减少长方法的大小，他们为同一任务创建了很多小型方法。我想知道它是否会影响应用程序的性能？

Answer 1

函数通常应该很短，在使用 Java 或 C# 进行编码时，我个人的“经验法则”是 5-15 行。这是一个很好的尺寸，原因如下:

• 无需滚动即可轻松适应您的屏幕
• 这是关于您可以在头脑中记住的概念尺寸
• 它本身就需要一个函数(作为独立的、有意义的逻辑 block )
• 小于 5 行的函数暗示您可能是将代码分解得太多(这使得阅读变得更加困难/了解您是否需要在功能之间导航)。要么那个或者您忘记了特殊情况/错误处理!

但我认为制定绝对规则没有帮助，因为总会有有效的异常(exception)/理由偏离规则:

• 执行类型转换的单行访问器函数显然是在某些情况下可以接受。
• 有一些非常简短但有用的函数(例如交换为用户未知提到的)显然需要少于 5 行。不是一个重要的是，一些 3 行函数不会对您的代码库造成任何损害。
• 作为单个大型 switch 语句的 100 行函数可能是如果正在做什么非常清楚，则可以接受。这段代码可以即使需要很多行，但概念上非常简单描述不同的情况。有时建议这样做应该重构为单独的类并使用继承/多态性，但恕我直言，这让 OOP 走得太远了 - 我会与其使用 40 个新类，不如使用一个大型 40 路 switch 语句处理。
• 一个复杂的函数可能有很多状态变量，这些变量会得到如果作为参数在不同函数之间传递，会非常困惑。在在这种情况下，您可以合理地论证代码是如果您将所有内容都放在一个大的文件中，则更容易理解函数(尽管马克正确地指出这也可能是一个成为一个类来封装逻辑和州)
• 有时更小或更大的函数具有性能优势(也许是因为 Frank 提到的内联或 JIT 原因)。这高度依赖于实现，但它可以产生影响 -确保进行基准测试!

所以基本上，使用常识，在大多数情况下坚持使用较小的函数大小，但如果您有真正充分的理由来创建一个异常大的函数，则不要教条化。

取自 here .