Класс Java Utility и службы

Ответ 1

Различные типы поведения могут быть получены с использованием различных объектов обслуживания. Статические методы в классе утилиты не могут быть заменены. Это чрезвычайно полезно для тестирования, изменения реализаций и других целей.

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

Ответ 2

Различие заключается в том, что классы обслуживания могут иметь состояние. И по государству я имею в виду разговорное состояние. Рассмотрим условную систему упорядочения.

interface OrderSystem {
  void login(String username, String password);
  List<Item> search(String criteria);
  void order(Item item);
  void order(Item item, int quantity);
  void update(Item item, int quantity);
  void remove(Item item);
  void checkout();
  Map<Item, Integer> getCart();
  void logout();
}

Такое может быть сделано с сеансом состояния beans (как один пример), хотя в этом случае аутентификация, вероятно, будет охватывать более традиционные механизмы EJB.

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

Услуга имеет гораздо более широкое значение, которое включает, но не ограничивается этим, следующее:

• с сохранением состояния;
• дистанционное; и
• зависит от реализации (т.е. через интерфейс).

Лучшей практикой, я думаю, является просто использовать статические методы в качестве удобных методов (особенно учитывая отсутствие у Java методов расширения). Услуги намного богаче.

Ответ 3

Вы не можете переопределить статический метод, который может представлять огромную проблему, если вы хотите реализовать свою услугу двумя разными способами и переключаться между ними. По этой причине я бы ограничил использование статических классов полезности простыми вещами, которые будут "никогда" (для достаточно долгого значения "никогда":)) необходимо выполнить несколькими способами.

Ответ 4

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

Обычно я использую статические методы для функциональности, которая требует нескольких параметров и может выполняться одним вызовом метода. Пример:

• вычислить значение хеша для строки
• конвертировать дату в стандартное представление

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

Типичный пример: соединение с базой данных, которое вы сначала подключаете, а затем используйте для выполнения запроса, а затем используйте, чтобы получить результат...

Ответ 5

Я ответил на этот вопрос здесь где-то раньше, но я обнаружил, что было очень легко изменить поведение службы - реорганизовать ее на несколько сервисов - там, где требуется довольно значительный рефакторинг, если вы используете статический класс.

Если это единственное отличие (и я считаю, что это так), то никогда не имеет смысла использовать статические классы.

Каждый раз, когда кто-то говорит: "Никогда не будет больше одного из них", код для них.