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类中是一个好主意吗？环顾四周，似乎没有关于这个主题的文章。我的观点是：

我应该这样做，因为：

我不必记住它是哪个助手类。（是FooHelper还是BarHelper？）
只是方便。我不必确定新的辅助方法是否值得拥有自己的辅助类，或者它是否适合现有的40个辅助类之一。
如果我制作了一个新的辅助方法，并且决定它应该得到自己的辅助课程，我可能会花一天的剩余时间“嘿，不会foobar（）在这个新课程中会更好吗？”
如果＃3是真的，其他程序员就会像“foobar（）去哪里去？它不在FoobarHelper！”

是否有帮助类的约定，如果没有，这会是一个糟糕的想法吗？

Answer 1

我认为你的问题不在于你有太多这些课程，而是你需要这些课程。

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

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

将所有助手类合并为一个巨大的类是一个好主意吗？

1 个答案: