为小型任务制作这么多方法也好吗？

Question

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

Answer 1

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

• 无需滚动即可轻松放入屏幕
• 这是关于你可以掌握的概念大小
• 它足够有意义，需要一个独立的功能（作为一个 独立的，有意义的逻辑块）
• 小于5行的功能可能是您的暗示 打破代码太多（这使得更难阅读/ 了解您是否需要在功能之间导航）。无论是那个还是 你忘记了你的特殊情况/错误处理！

但我不认为设置绝对规则是有帮助的，因为总会有有效的例外/理由偏离规则：

• 显然执行类型转换的单行存取器函数 在某些情况下可以接受。
• 有一些非常短但有用的功能（例如，交换为 用户未知提到，显然需要不到5行。不是 重要的是，一些3行函数不会对你的代码库造成任何伤害。
• 100行函数可能是单个大型switch语句 如果非常清楚正在做什么，那就可以接受。这段代码可以 在概念上非常简单，即使它需要很多行 描述不同的情况。有时建议这样做 应该重构为单独的类并使用 继承/多态，但恕我直言这是OOP太远 - 我 而是有一个40个新的40个开关语句而不是40个新类 处理。
• 复杂的函数可能会有很多状态变量 如果在不同的函数之间作为参数传递，则非常混乱在 在这种情况下，你可以合理地提出代码的论点 如果将所有内容保存在一个大的内容中，则更简单，更容易理解 功能（虽然马克正确地指出这也可能是一个 变成一个类来封装逻辑和逻辑的候选者 状态）
• 有时较小或较大的功能具有性能优势 （也许是因为Frank提到的内联或JIT原因）。这个 是高度依赖实现的，但它可以有所作为 - 确保你的基准！

所以基本上，使用常识，在大多数情况下坚持使用小功能，但如果你有一个非常好的理由去做一个非常大的功能，那就不要教条了。

取自here。

Answer 2

在一般情况下不可能说，但不是，可能不是。

首先：方法调用真的非常快。

另一方面，JVM监视代码完成的工作，当它看到“热点”（代码的一部分运行很多）时，它会积极地优化代码的这一部分。其中一种方法是在可能的情况下内联方法 - 即，将方法中的代码重新定位到调用它的方法中。此时，性能与您自己放置代码的效果相同。因此，您可以获得小方法的维护和可测试性优势，但内联代码的好处如果则有助于内联它。

但是，在一般情况下，它无法回答。如果您遇到特定的性能问题，请benchmark查看在特定情况下是否重要。