将所有助手类合并到一个巨大的类中是个好主意吗？答案

【问题标题】：Is it a good idea to merge all helper classes into one gigantic class?将所有助手类合并到一个巨大的类中是个好主意吗？
【发布时间】：2014-09-30 19:57:11
【问题描述】：

当我开发我的软件时，我倾向于发现自己创建了大量的 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 类是个好主意吗？环顾四周，似乎没有关于这个主题的任何内容。我的看法是：

我应该这样做，因为：

我不必记住它在哪个助手类中。（是 FooHelper 还是 BarHelper？）
只是方便。我不必决定新的辅助方法是否值得拥有自己的辅助类，或者它是否适合现有的 40 个辅助类之一。
如果我创建了一个新的辅助方法，并认为它值得拥有自己的辅助类，我可能会在剩下的时间里度过“嘿，在这个新类中 foobar() 会不会更好？”
如果 #3 为真，其他程序员会说“foobar() 到底去了哪里？它不在 FoobarHelper 中！”

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

【问题讨论】：

你为什么要创建这么多帮助类？这已经表明您的代码设计可能有问题。
在创建这么多辅助类时，您应该真正考虑一下您的代码。
我怀疑这个问题可能会因为过于广泛/基于意见而接近。有些人会说是合并它们，其他人不会。其他人仍然会说为什么您根本没有任何助手或只合并相关的助手； JDK 库有 Objects、Arrays、Bits、Collections 等。在一天结束时，试一试，看看什么对你来说最易读和可维护。
凝聚力。这就是工作原理。如果将任何实用程序方法合并到一个类中，它们之间是否会有凝聚力？

标签： java helper convention

【解决方案1】：

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

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

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

【讨论】：