为什么更短的方法更好


DR
较长的方法更有可能在应用程序更改时需要更改。

更长的故事
更短的方法在很多方面保护了我在代码上的投资。

第一:可测试性。我期望在方法长度(“语句”的数量)和完全验证方法所需的(单元)测试用例的数量之间存在相关性。实际上,随着方法大小的增加,我预计测试用例的数量通常会比线性增长更快。因此,将一个大的方法分解成较小的独立方法意味着我可以相互独立地测试应用程序的部分行为,而且可能只需要较少的测试。所有这些都意味着,与大型方法所需的投资相比,我在创建和运行一组小型方法的测试时所需的投资将更少。

第二:凝聚力。我预计方法长度和要求该方法更改的未知未来需求的数量之间有很强的相关性。由此可见,我在开发和测试一个小方法上所做的投资将会得到无数次的回报,因为以后我将会有更少的理由去打破它,撤销我所做的事情。较小的方法更有可能“稳定下来”,并从应用程序的整体变动中退出。

第三:耦合(DRY)。我预计,较长的方法更有可能复制在同一代码库中其他地方找到的知识或逻辑。这再次意味着,如果那些重复的知识必须改变,我为使这个(长)方法正确所投入的努力可能会付诸东流。

最后:可理解性。与较长时间的方法相比,做得很少的方法很可能需要较少的脑力体操来完全理解。我不太可能在每次遇到它的时候都要投入大量的时间。

开闭原则说,我们应该努力设计我们的应用程序,以便在不需要更改现有代码的情况下可以添加新的特性--因为这种状态保护了我们在现有的工作代码中所做的投资,并且消除了如果我们打开并更改它时破坏它的风险。也许也值得将OCP视为同样适用于方法。