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

Question

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

Answer 1

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

• 无需滚动即可轻松适应您的屏幕
• 这是关于你可以在头脑中记住的概念尺寸
• 它足够有意义，需要一个独立的函数（作为一个独立的、有意义的逻辑块）
• 小于 5 行的函数暗示您可能过多地分解了代码（如果您需要在函数之间导航，这会使阅读/理解变得更加困难）。要么就是你忘记了你的特殊情况/错误处理！

但我认为制定绝对规则没有帮助，因为总会有有效的例外/理由偏离规则：

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

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

取自这里。