Эффективный объект Java 1 применимость с TDD и внедрением зависимости
Я читал Эффективный Java, и у меня есть некоторые проблемы относительно первого Объекта, "используют статический метод фабрики вместо конструктора" относительно TDD и внедрения зависимости.
Объект говорит, что необходимо постараться не иметь общественность/защищать/конструктора по умолчанию и выставить ее с помощью статической фабрики. Я соглашаюсь со всеми преимуществами, связанными с использованием статических фабрик как фабрики, может иметь имя, можно возвратить подтип, можно уменьшить многословие и т.д. Но, я думаю в недостатках, Joshua пропустил TDD, потому что наличие статических фабрик в Вашем коде приведет к плотному соединению, и Вы не можете дразнить класс с помощью него. Мы не сможем дразнить класс, который будет иметь статические фабрики. Так, это препятствует разработке через тестирование.
Вторая точка, я думаю, что он пропустил это в сегодняшнем развитии предпринимательства, которое большинство приложений использует один или другой контейнер внедрения зависимости. Так, когда мы можем ввести зависимости с помощью DI итак, почему я должен использовать его.
Объясните, как это относится к сегодняшнему развитию предпринимательства Java, которое включает DI и TDD.
2 ответа
Двигатель DI является фабрикой.
Джошуа Блох достаточно хорошо понимает DI. Я думаю, что это артефакт истории, потому что восхождение DI произошло после выхода первого издания "Effective Java".
"Эффективная Java" была опубликована в 2001 году. Мартин Фаулер ввел этот термин в 2004 году. Релиз Spring 1.0 состоялся в марте 2004 года.
Джошуа Блох не стал изменять эту главу для второго издания.
Суть в связи, которую вводит "new". Любой, кто понимает это и фабрики, легко сделает скачок к DI-двигателям. Дело в том, что его утверждения относительно "new" и средства защиты от использования фабрик по-прежнему верны.
Я вижу здесь 2 отдельные проблемы:
- статические фабрики против использования new ()
- инъекция зависимостей
При использовании new ваш код так же тесно связан, как и при использовании статического метода, на самом деле даже хуже, поскольку статический factory может творить чудеса и возвращать некоторую конкретную реализацию, если это подкласс или реализация интерфейса.
В случае внедрения зависимости принцип также называется принципом Голливуда: «Не звоните нам, мы позвоним вам». Таким образом, в этой философии вы не должны вызывать new () или статическую фабрику в своем коде, но пусть внешняя вещь сделает это за вас, либо фреймворк DI, либо модульный тест. Это не имеет ничего общего с фабриками или использованием новых, поскольку это делается где-то еще.
В этом случае фабрики лучше, потому что вы можете ввести тестовую фабрику под свой контроль. С новым это невозможно (без каких-либо странных вещей в пути к классам, таких как скрытие реализации с помощью фиктивных объектов в пути к тестовым классам, что, кстати, я не рекомендую).