java - 将所有辅助类合并到一个巨大的类中是个好主意吗？

Question

当我开发我的软件时，我往往会发现自己创建了大量的 ThingyHelper.java、FooHelper.java、BarHelper.java 等。我数了一下，在我正在处理的当前项目中，有超过 40 个类，看起来像这样:

public final class FoobarHelper {
  // Prevent instantiation
  private FoobarHelper() {throw new AssertionError();}

  public static void doSomething() {}
  public static int foobar() {}
  // And many more
}

我的问题是:将所有这些类合并到一个巨大的 Helper.java 类中是一个好主意吗？环顾四周，似乎没有关于这个话题的文章。我的看法是:

我应该这样做，因为:

1. 我不必记住它在哪个帮助器类中。(是 FooHelper 还是 BarHelper？)
2. 只是方便而已。我不必决定新的帮助器方法是否值得拥有自己的帮助器类，或者它是否适合现有的 40 个帮助器类之一。
3. 如果我创建一个新的帮助器方法，并认为它值得拥有自己的帮助器类，我可能会花一整天的时间“嘿，foobar() 在这个新类中不是会更好吗？”
4. 如果#3 为真，其他程序员会说“foobar() 到底去了哪里？它不在 FoobarHelper 中!”

辅助类是否有约定，如果没有，这会是一个糟糕的主意吗？

Answer 1

我认为你的问题不是你有太多这些类，而是你完全需要这些类。

面向对象的核心思想是将功能和数据合并到对象中，然后代表程序流程。在不了解您的应用程序的情况下，您的实用程序类建议您使用无生命的 bean 类，然后由服务函数层处理这些类。这是过程式编程的标志，您不想用 Java 实现任何内容。

除此之外，没有理由合并您的实用程序方法。所以我对你的问题的回答是不。实用程序类有一些合法的用途，例如 Java 的 Math 、Collections 类(这些类也更适合作为对象方法，但语言限制/限制了此类定义)，您可能刚刚遇到过其中之一。请注意 Java 如何决定按语义对此类实用方法进行分组。在一个 namespace 中定义实用程序方法是有意义的，这样您的 IDE 就可以在您仅键入类时帮助您选择一个函数(在这种情况下，该类并不代表真正的类，而是代表函数 namespace )。归根结底，还是要找到一个平衡点。如果每个类只有一个实用方法，其他人就很难找到这些方法，因为他们需要知道类的名称。如果只有一个实用程序类，则定位所有提供的实用程序类中的一个函数可能会出现问题。将实用程序类视为导航助手( namespace )的一种形式，并根据您认为直观的内容做出决定。