是否值得提取仅在类中调用一次的代码的私有方法，或者将代码留在父方法（可能）中，并使用注释来说明它的作用？
答案 0 :(得分：14)
如果它澄清了代码的意图，总是值得提取方法。
对于很长的方法尤其如此。虽然评论很好，但它们并没有描述（至少不是以非常可靠的方式）它解释的过程结束的地方以及下一个开始的地方。有时，在提取方法之后，常见的抽象只会变得更加明显。
如果您正在进行自动化单元测试（不一定是TDD），对单元测试较小的方法进行单元测试也会更加容易得多 - 尽管您可能需要根据测试结果公开您的方法你使用的框架。
关键是，小方法不会出错，特别是如果它们具有描述性名称。
答案 1 :(得分：3)
是的，是的。
另外一点：对于简单的辅助方法，您可能希望将它们设置为静态（这样它们不依赖或改变其实例的状态），然后您可以将它们公开以便更容易重用。
答案 2 :(得分：2)
这样做有很大的好处。这完全取决于信息隐藏，并使意图非常明确。
在Refactoring to Code中，他们调用了这种组合方法，您可以将大型方法分解为许多较小的方法。这样做有两件事。
首先，它减少了在处理父方法时需要担心的大量信息。
其次，方法的名称应该表明其意图使代码更具可读性。
答案 3 :(得分：1)
当然！方法越小，维护软件就越容易。
答案 4 :(得分：1)
对我来说，这取决于代码的大小，以及它与父方法的作用有多大关系。如果它是很多代码（例如超过5-10行代码，或超过父方法中代码总量的50％），我会将其提取到私有方法，以获得代码结构和可读性。否则，我会将它留在带有描述性注释的父方法中。
我认为如果代码中有太多非常小的方法，可维护性和可读性会降低。我力求平衡。但每当我怀疑;我将其作为私有方法提取。
答案 5 :(得分：0)
只是一个愚蠢的估计，但我会说大多数私人方法只能在普通班级的几个地方被调用。但是，如上所述，如果将所有功能分解为逻辑块，它将使您的代码更易读，更容易测试/维护。重构是一个好习惯
答案 6 :(得分：0)
您应该根据API的设计进行重构。在其他地方使用时要公开的方法/属性。您不应该考虑使用它来决定是否将其设为私人/公共。