Является ли хорошей идеей объединить все вспомогательные классы в один гигантский класс?

1

Когда я разрабатываю свое программное обеспечение, я, как правило, создаю целую тонну 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!"

Есть ли соглашение для вспомогательных классов, или если нет, было бы ужасной идеей?

  • 0
    Почему вы создаете так много вспомогательных классов? Это уже признак того, что может быть что-то не так с дизайном вашего кода.
  • 0
    Вы должны действительно думать о своем коде, когда вы создаете много вспомогательных классов.
Показать ещё 2 комментария
Теги:
helper
convention

1 ответ

1
Лучший ответ

Я утверждаю, что ваша проблема заключается не в том, что у вас слишком много этих классов, а в том, что вам нужны эти классы вообще.

Основная идея объектной ориентации заключается в объединении функциональных возможностей и данных в объекты, которые затем представляют ваш программный поток. Не зная приложения, ваши классы полезности предлагают использовать неживые классы компонентов, которые затем обрабатываются слоем служебных функций. Это признак процедурного программирования и ничего не нужно реализовать с помощью Java.

Кроме того, нет никаких оснований для объединения ваших методов утилиты. Так что я бы ответил не на ваш вопрос. Существуют некоторые законные применения классов полезности, таких как классы Java Math, Collections (они также будут лучше сочетаться с объектными методами, но языковые ограничения/ограничивают такое определение), и вы могли бы просто столкнуться с одним из них. Обратите внимание, что Java решила сгруппировать такие методы полезности по своей семантике. Имеет смысл определить методы утилиты в одном пространстве имен, чтобы ваша среда IDE могла помочь вам выбрать функцию, когда вы вводите только класс (который не представляет собой настоящий класс, а скорее пространство имен функций в этом контексте). В конце концов, речь идет о поиске баланса. Если у вас есть один метод утилиты для каждого класса, для других трудно найти эти методы, поскольку они должны знать о имени класса. Если есть только один класс утилиты, может оказаться проблематичным найти функцию всех предложенных. Подумайте о классе утилиты как о форме помощника навигации (пространство имен) и решите, что вы найдете интуитивно понятным.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню