Следует ли избегать статических классов, потому что это затрудняет внедрение зависимостей?

Question

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

Лично я думаю, что это воняет, потому что у нас теперь есть базовый набор библиотек, которые сложно протестировать, потому что я не могу смоделировать / заглушить эти классы или сделать какие-то инъекции в их конструкторы.

Полагаю, я могу использовать TypeMock, но я бы предпочел сделать это бесплатно.

Что ты думаешь?

Редактировать

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

Answer 1

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

Но у меня тоже плохое предчувствие по поводу упомянутых вами дел. Я знаю некоторые из этих статических служебных классов «обертки» - и в большинстве случаев они действительно воняют:)

EDIT:
Может быть, я должен уточнить. Я бы использовал статические классы / методы только для очень маленьких задач. Когда статические классы начинают инициализировать зависимости, их, безусловно, следует избегать. Если вы не можете протестировать эти статические классы, у них уже есть слишком большая работа.

В первом ответе на этот вопрос - аргументы против статических классов, как вы упомянули.

Answer 2

Из Journal of Object Technology: отделение ответственности от статических методов для детальной настройки

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

Answer 3

Насколько сложно было бы изменить эти статические классы, чтобы использовать Dependency Injection? Если вы сделаете DI необязательным (если это возможно), вы, по сути, можете создать ситуацию, в которой вы можете использовать статические классы для насмешки, просто выполняя DI, не меняя при этом никакого «нормального» поведения.