Ответ.

История вопроса

С самого начала Java разрабатывалась как объектно-ориентированный язык, где основная задача решалась созданием экземпляров классов. Однако для часто используемых методов (например, сортировки, преобразования данных) начали появляться классы-утилиты с набором статических методов (например, java.util.Collections).

Проблема

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

Решение

• Классы-утилиты (utility classes) — набор статических методов без состояния, не требуют создания объекта. Хороши для манипуляций над коллекциями, преобразований, математических операций.

• Экземпляры классов — хранят состояние, используют зависимости, обеспечивают расширяемость и тестируемость. Применяются в бизнес-логике, сервисах, контроллерах и т.д.

Пример кода:

// Пример класса-утилиты
public class MathUtils {
    public static int add(int a, int b) {
        return a + b;
    }
}

// Использование: int sum = MathUtils.add(1, 2);

// Пример экземпляра класса для бизнес-логики
public class OrderService {
    private final OrderRepository repo;
    public OrderService(OrderRepository repo) {
        this.repo = repo;
    }
    public void placeOrder(Order o) {
        repo.save(o);
    }
}

Ключевые особенности:

• Stateless и не подлежат тестированию в изоляции — классы-утилиты.
• Классы с состоянием легко заменять через внедрение зависимостей (DI).
• Классы-утилиты часто финализируются и имеют приватный конструктор.

Вопросы с подвохом.

Можно ли наследовать классы-утилиты и расширять их статические методы?

Нет, обычно классы-утилиты объявляют как final, с приватным конструктором. Наследование статических методов доступно, но не имеет смысла, так как статические методы не наследуются на уровне вызова экземпляра.

Пример кода:

public final class MyUtils {
    private MyUtils() {} // предотвращает создание экземпляра
}

Могут ли классы-утилиты содержать состояние?

Нет. Если утилитный класс содержит состояние (instance или static поля), это нарушает принцип написания утилит, ведет к ошибкам многопоточности и ухудшает читаемость.

Можно ли мокать статические методы классов-утилит при тестировании?

Только с помощью специальных инструментов типа PowerMock, которые делают тесты более сложными и иногда нестабильными. В обычных случаях DI-friendly подход с экземпляром предпочтительнее для тестов.

Типовые ошибки и анти-паттерны

• Нарушение принципа single responsibility: утилиты начинают хранить состояние.
• Наследование или расширение классов-утилит.
• Использование статических методов там, где требуется учёт состояния (например, бизнес-сервисы).

Пример из жизни

Негативный кейс

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

Плюсы:

• Быстрый старт.
• Простота вызовов.

Минусы:

• Отсутствие тестируемости.
• Проблемы с выделением ответственности.

Позитивный кейс

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

Плюсы:

• Гибкость архитектуры, хорошая расширяемость.
• Отличная тестируемость.

Минусы:

• Больше кода на описание классов и внедрение зависимостей.