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

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

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


person AbstruselyArcane    schedule 07.08.2014    source источник
comment
Почему вы создаете так много вспомогательных классов? Это уже признак того, что с дизайном вашего кода что-то не так.   -  person Jesper    schedule 07.08.2014
comment
вы должны действительно думать о своем коде, когда создаете столько вспомогательных классов.   -  person Philipp Sander    schedule 07.08.2014
comment
Я подозреваю, что этот вопрос может быть слишком широким / основанным на мнении. Некоторые люди сказали бы да объединить их, другие нет. А другие по-прежнему будут говорить, почему у вас вообще есть какие-либо помощники или нужно объединять только связанные помощники; в библиотеках JDK есть объекты, массивы, биты, коллекции и т. д. В конце концов, попробуйте и посмотрите, что для вас наиболее удобно для чтения и сопровождения.   -  person Chris K    schedule 07.08.2014
comment
Сплоченность. Это принцип работы. Будет ли связь между какими-либо служебными методами, если они объединены в один класс?   -  person kolossus    schedule 07.08.2014


Ответы (1)


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

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

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

person Rafael Winterhalter    schedule 07.08.2014