Эффективная применимость пункта 1 Java с внедрением TDD и зависимостей

Question

Я читал «Эффективную Java», и у меня есть некоторые опасения, связанные с первым пунктом «Использование статического метода фабрики вместо конструктора» в отношении TDD и внедрения зависимостей.

Элемент говорит, что вам следует избегать использования конструктора public / protected / default и выставлять его с помощью статической фабрики.Я согласен со всеми преимуществами, связанными с использованием статических фабрик, например, у фабрик может быть имя, вы можете вернуть подтип, вы можете уменьшить многословность и т. Д. Но, я думаю, в недостатках Джошуа пропустил TDD, потому что наличие статических фабрик в вашем коде приведет к тесной связи иВы не можете издеваться над классом, используя его.Мы не сможем издеваться над классом, который будет иметь статические фабрики.Таким образом, это затрудняет разработку через тестирование.

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

Пожалуйста, объясните, как это применимо к современной разработке Java-приложений для предприятий, которая включает DI и TDD.

Answer 1

Двигатель DI является заводским.

Джошуа Блох понимает меня достаточно хорошо. Я думаю, что это исторический артефакт, потому что восхождение DI произошло после первого издания «Effective Java».

"Эффективная Java" была опубликована в 2001 . Мартин Фаулер придумал термин в 2004 году. Релиз Spring 1.0 вышел в марте 2004 года.

Джошуа Блох не изменил эту главу для второго издания.

Дело в том, что «новое» вводит связь. Любой, кто понимает это и фабрики, легко сделает скачок к двигателям DI. Дело в том, что его утверждения о «новом» и о способах использования фабрик по-прежнему верны.

Answer 2

Здесь я вижу 2 отдельных вопроса:

• статические фабрики против использования new ()
• Внедрение зависимости

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

С внедрением зависимости также называется принцип Голливуда: «Не звони нам, мы позвоним тебе». Таким образом, в этой философии вы не должны вызывать new () или статическую фабрику в вашем коде, но должны иметь внешнюю вещь, которая делает это за вас, либо инфраструктуру DI, либо модульный тест. Это не имеет ничего общего с фабриками или использованием новых, как это делается где-то еще.

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

Answer 3

У меня была такая же проблема, как и у вас, и вот как я нашел ваш вопрос.

Вы говорите:

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

книга предлагает вам предоставить конструктору вашего класса статический метод (api design). Он не предполагает, что вы «жестко кодируете» статический вызов во всем приложении (использование API).

Предположим, вы используете Guice for DI, и ваш интерфейс называется Connection, вы можете сделать:

bind(Connection.class).toInstance(Connections.makeASpecificConnection(params));

А потом твой обычный @Inject Connection connection;

Конечно, это если ваше соединение синглтон. Если это не так, вы можете внедрить Abstract Factory с помощью реализации, которая создает экземпляры, вызывающие статический метод вашего класса, но это может быть слишком излишним, и вам лучше использовать только Guice.

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

Хотя эта книга не нацелена исключительно на разработчиков многоразового использования компоненты, это неизбежно окрашивается моим опытом написания таких компоненты за последние два десятилетия. Я естественно думаю с точки зрения экспортируемые API (интерфейсы прикладного программирования), и я призываю Вы должны сделать так же.