c# - 当它只被调用一次时，创建一个辅助方法仍然有意义吗？

Question

我经常发现自己创建了一些方法来保存小型（<50 行）算法。然而，当我第一次学习方法时，我们不断地被告知它们是一种通过将常用代码片段包含在一个块中来压缩/清理代码的方法。

我不仅喜欢使用方法来达到这个目的，而且还喜欢使用小片段，以便我的主要方法清晰易懂，并且代码的“肉”隐藏在这些方法中。从风格上讲，这是不正确的吗？

Answer 1

将大方法分解成较小的方法以提高可读性并没有错。

它有几个好处，特别是如果您将每个方法保持在一个抽象级别 - 使大方法可以流畅地阅读，并使每个小方法简单易懂。

Answer 2

从风格上讲，至少从我的经验来看，这并没有错。我这么说的原因是，一个程序，如果由一个或一百个程序员编写，将由那个程序员/程序员的才能和经验组成和完成。这意味着有很多方法可以解决问题，您应该问自己的问题是我的实现是否有效？它是否完成了任务/功能？如果是这样，那就太好了！

因为你关心风格，所以我会向你推荐 Bob 叔叔的 SOLID 原则，就像许多其他人在风格上遇到类似问题一样。您提到在单个方法中有一个由 <50 行代码组成的算法，我认为尽可能地尝试遵循鲍勃叔叔的单一责任（SOLID 中的“S”）原则。这将挑战您查看 <50 line-in-a-single-method 算法，并考虑将其分解为更多专注于做一件事和做好一件事的方法。这样你就可以实现可测试性和可读性。这总是两件事，对“好风格”有很长的路要走。

Answer 3

不，这不是不正确的。编写代码时应该有多个目标。不通过将代码合并到可重用的类和方法中来重复代码说明了可维护性。将工作项分解为单独的方法可以提高可读性，这也恰好有助于未来的可维护性。

像所有事物一样，需要寻求平衡。必须在心理上遍历调用堆栈的太多级别才能理解算法或发现缺陷可能会成为一个缺点。但是如果一个方法大约有 50 行，我很难相信你会遇到这种情况。