将大型方法分解为较小的方法时，适当的访问级别实践？

Question

所以我是一个相对较新的程序员，仍在学习，并且遇到了一些问题（所以如果我的标签有点偏离，我深表歉意）。早些时候，我有机会阅读一篇文章，讨论将包含大量代码的方法分解为对许多较小的、名称明确的方法的调用集的优点。总的来说，我觉得这使得代码看起来更干净，并且确实使单元测试变得更加容易。然而，我对是否将所有这些新方法公开还是私有有些担心。将它们设为私有似乎是正确的做法，因为其余代码通常不需要访问这些方法。然而，单元测试私有方法可能会很混乱。这有最佳实践吗？

我现在正在做的事情：

 public class WashingMachine {
      public Load wash(Load load) {
           // Removes one sock from load
           for (ClothingItem item : load.getItems()) {
                if (item.getType().equalsIgnoreCase("sock") {
                     load.removeItem(item);
                     .. // logic for sending sock to proper dimension
                     break;
                }
           }
           // rest of logic for cleaning clothes
      }
 }

变成：

 public class WashingMachine {
      // Wash a load of laundry
      public Load wash(Load load) {
           // Removes one sock from load
           removeSock(load.getItems());
           // rest of logic for cleaning clothes
           ..
      }

      // Oh no, I can't unit test this easily!
      private void removeSock(List<ClothingItem> items) {
           ...
      }
 }

Answer 1

将您的公共方法视为您希望允许任何人使用的功能。

其中一些功能可能很复杂，您是对的，该功能应该分为不同的方法。问题是，“他们有什么样的访问权限？”

好吧，如果它们是公共的，那么现在外部类可以访问您的内部功能，而这是您真正不想要的。即使它不会破坏任何东西，当您开始处理大型项目（与更大的团队）时，通过将其公开，其他程序员可能会使用该功能，这现在会阻止您更改它。

例如，以汽车为例。假设您的方法是 accelerate()。这可能会调用releaseGas()。但是，您不希望外部任何人释放气体。仅应在受控环境中调用它。

然后是受保护的访问。受保护的访问适用于可能被扩展类覆盖的方法。这些应该是执行与内部功能相关的特定工作块的方法。再次以汽车为例，可能有一个 RaceCar 类使用特殊类型的气体，因此它希望提供自己的释放气体的方法。这将是 releaseGas 受到保护的一个原因。

至于测试，您应该主要测试您的公共合约。这是其他类使用的内容，最后，这才是真正重要的。您的内部方法是您功能的内部方法，并将通过测试您的公共合约来进行测试。这也意味着您的类应该首先根据其外部用途进行设计，然后围绕它构建测试。 （即使使用测试驱动的开发，随着您获得经验，这也会变得更容易。）

当然，有时这些内部方法足够复杂，以至于它们需要自己的单元测试。但是，您不需要保护它们。在这种情况下，您可以将它们设置为默认访问权限。 （既不是公开的也不是受保护的）。只要您的单元测试位于同一个包中，您就可以调用它们。

更好的是，如果您知道不希望任何人扩展它，但需要对其进行测试，请将其设置为 protected final 或只是 final。这仍然允许调用它，但至少可以防止它被覆盖。

编辑：

瑞安下面的评论是正确的。如果您的类变得足够复杂，需要测试其内部方法，那么可能应该将这些方法提取到它们自己的类中，然后可以对其进行独立的单元测试。

总的来说，您的测试应该测试各个单元的公共合同。

Answer 2

我认为您应该根据将调用它的（主要的，而不是测试的）代码来设计您的类。如果没有人需要调用 WashingMachine.removeSock() 那么我会将其保留为私有。

至于单元测试，这当然意味着您无法在 WashingMachine 中测试这一单独的逻辑 - 但您仍然可以测试 wash() 方法，如果这是使用 WashingMachine 的其他组件所可见的全部内容，也是您真正需要关注测试的内容。

编写的单元测试可能太且关注细节。