將所有幫助程序類合並為一個巨大的類是一個好主意嗎？

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如何決定按其語義對此類實用程序方法進行分組。 在一個名稱空間中定義實用程序方法是有意義的，這樣，當您僅鍵入類時（在這種情況下，它並不代表真正的類，而是一個函數名稱空間），IDE可以幫助您選擇一個函數。 最后，這是找到平衡。 如果每個類只有一個實用程序方法，那么其他人就很難找到這些方法，因為他們需要知道類的名稱。 如果只有一個實用程序類，則可能無法找到所有提供的功能。 將實用程序類考慮為導航助手（名稱空間）的一種形式，然后決定您認為直觀的內容。