以面向对象的方式思考

Question

每当我认为我对OOP有了一些信心时，突然间我被一些先进的例子所咬住。 就像鲍伯叔叔在这篇非常棒的文章中一样，他使用以下课程作为他的kata的例子。

 public class WordWrapper {
      private int length;

  public WordWrapper(int length) {
    this.length = length;
  }

  public static String wrap(String s, int length) {
    return new WordWrapper(length).wrap(s);
  }

  public String wrap(String s) {
    if (length < 1)
      throw new InvalidArgument();
    if (s == null)
      return "";

    if (s.length() <= length)
      return s;
    else {
      int space = s.indexOf(" ");
      if (space >= 0) 
        return breakBetween(s, space, space + 1);
      else
        return breakBetween(s, length, length);
    }
  }

  private String breakBetween(String s, int start, int end) {
    return s.substring(0, start) + 
      "\n" + 
      wrap(s.substring(end), length);
  }

  public static class InvalidArgument extends RuntimeException {
  }
}

我有以下疑问：

1. 为什么使用静态辅助方法wrap ？
2. 为什么InvalidArgument类是嵌套的并且是静态的？
3. 为什么我们甚至需要初始化该类，因为它只不过是一种算法，并且可以在没有任何实例变量的情况下运行，为什么我们需要〜100个实例（例如）？

Answer 1

1. 为什么使用静态辅助方法包装？

没有特别好的理由-我认为这是一个主观判断：

WordWrapper.wrap("foo", 5);

比

new WordWrapper(5).wrap("foo");

（我同意）。 当代码感觉很重复时，我倾向于发现自己添加了这样的方法。

但是，静态形式可能会导致隐藏的问题：在循环中调用它会导致创建许多不必要的WordWrapper实例，而非静态形式只会创建一个并重用它。

2. 为什么InvalidArgument类是嵌套的并且是静态的？

嵌套它的含义是，它仅用于报告WordWrapper中方法的无效参数。 例如，如果一些与数据库相关的类抛出了WordWrapper.InvalidArgument实例，那将没有多大意义。

请记住，为方便起见，可以将其作为InvalidArgument引用（如果已正确导入）； 您仍然始终使用some.packagename.WordWrapper.InvalidArgument ，因此在其他类中使用它在语义上没有意义。

如果希望在其他类中使用它，则不应嵌套它。

至于为什么static ：我可以想到两个原因（这是同一枚硬币的不同方面）：

1. 它不需要是非静态的 。 非静态嵌套类称为内部类。 它与创建它的包含类的实例有关。 在某种程度上，内部类中的数据与外部类中的数据相关。

   这实际上意味着在创建外部类时将隐式引用传递给内部类。 如果您永远不需要引用此实例，请将其设为静态，这样就不会传递引用。 这就像删除方法的未使用参数：如果不需要它，则不要传递它。

2. 持有此参考具有不可预期的后果 。 （我将这一点作为一个单独的观点，因为尽管前一个参考是指对参考的逻辑要求/不参考，但这是指持有该参考的实际含义）。

   就像保留任何引用一样，如果您具有对内部类实例的引用，则使它引用的所有内容都不符合垃圾回收的条件，因为它仍然可以访问。 根据您使用内部类实例的方式，这可能导致内存泄漏。 该类的静态版本不会遇到此问题，因为没有引用：清除所有Wrapper实例后，您就可以引用InvalidArgument 。

   另一个后果是InvalidArgument的约定无效： Throwable是InvalidArgument的超类，实现了Serializable ，这意味着InvalidArgument也实现了Serializable 。 但是， WordWrapper不可Serializable 。 这样，由于对WordWrapper的非空引用，非静态InvalidArgument序列化将失败。

   解决这两个问题的简单方法是使嵌套类static ; 作为一种防御策略，除非您确实不需要它们，否则应将所有嵌套类设为静态。

3. 为什么我们甚至需要初始化此类，因为它只不过是一种算法而已...

好问题。 这与您的第一个问题有关：您可以只使用静态帮助器方法，然后删除实例方法和状态。

在放弃实例方法之前，实例方法比静态方法有很多优势。

显而易见的是，您能够在实例中存储状态，例如length 。 这使您可以传递更少的参数来wrap ，这可能会使代码的重复性降低。 我想它的效果有点像局部评估。 （您也可以将状态存储在静态变量中，但是全局可变状态是一种皇家PITA；这是另一回事了）。

静态方法紧密耦合 ：使用WordWrapper的类与特定的自动换行实现紧密绑定。

对于许多目的，一种实现可能很好。 但是，几乎总是有至少两种实现方式（您的生产和测试实现方式）。

因此，以下内容与一个实现紧密相关：

void doStuffWithAString(String s) {
  // Do something....
  WordWrapper.wrap(s, 100);
  // Do something else ....
}

以下可以在运行时提供实现：

void doStuffWithAString(WordWrapper wrapper, String s) {
  // Do something....
  wrapper.wrap(s);
  // Do something else ....
}

使用wrapper作为策略 。

现在，您可以选择用于特定情况的自动换行算法（例如，一种算法在英语中效果很好，而另一种算法在中文中效果更好-也许，我不知道，这只是一个例子）。

或者，对于测试，您可以为测试注入一个模拟的实例，该实例仅返回参数-这使您可以测试doStuffWithAString而无需同时测试WordWrapper的实现。

但是，灵活性带来了开销。 静态方法更加简洁。 对于非常简单的方法，很可能会采用静态方法。 随着方法变得越来越复杂（尤其是在测试用例中，越来越难以计算出输入以提供对测试用例很重要的特定输出），实例方法形式将成为更好的选择。

最终，没有硬性规定可以使用。 请同时注意两者，并注意在给定情况下哪种效果最好。