2014-12-13 3 views
2

Я хочу уменьшить сцепление между двумя компонентами, тогда я подумал о dependency injection, но в течение длительного времени я просто использую Spring для реализации этого. Но теперь я работаю над проектом, который не подходит для использования этой фреймворка (он слишком тяжелый).Можете ли вы дать мне пример инъекции зависимостей без фреймворков?

Можете ли вы привести мне пример для реализации dependency injection для себя?

+0

Что относительно Guice? –

ответ

0

Почему вы хотите изобрести колесо? Java имеет отличную инфраструктуру CDI. Его легкий и простой в использовании. Для получения дополнительной информации см. http://docs.oracle.com/javaee/6/tutorial/doc/giwhl.html

+1

Если весна слишком тяжелая, то контейнер JEE, вероятно, будет слишком тяжелым, а также –

2

Dependency Injection - это шаблон, который можно легко использовать без поддержки каркаса. Некоторые даже предпочитают его без поддержки фреймворка, но, по крайней мере, независимо от того, действительно ли платформа действительно выгодна, зависит от way you use such framework и типа и размера приложения, которое вы создаете/поддерживаете.

Зависимость от инъекции - это просто введение инъекций в компонент снаружи. Наиболее распространенный и рекомендуемый способ сделать это - через инъекцию конструктора. Это означает, что класс должен указывать все свои зависимости как аргументы конструктора.

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

Использование инъекции зависимостей «пузырится» во всем приложении. Это означает, что класс, применяющий шаблон внедрения зависимостей, перенесет ответственность за создание зависимостей над стеком вызовов. Это означает, что потребитель этого класса теперь становится ответственным за создание своих зависимостей. Но поскольку этот потребитель должен также применять инъекцию зависимостей, это означает, что он снова ставит ответственность за создание зависимостей. Когда все классы применяют шаблон инъекции зависимостей, это означает, что полный граф объектов должен быть создан в одном месте приложения. На самом деле это хорошо. Это место называется composition root.

Опять же, вам не нужно использовать библиотеку DI (контейнер IoC.a.a. IoC), и ваш код приложения определенно не зависит от него. Вы должны применить шаблон Injection Dependency (и принципы SOLID), чтобы сделать ваше приложение удобным. Библиотека DI может использоваться, чтобы сделать ваш корневой каталог поддерживаемым, но он должен ТОЛЬКО использоваться, если он делает корневой состав более удобным. Не используя библиотеку DI, вы получаете полную поддержку времени компиляции при создании графиков объектов. Использование библиотеки DI позволит вам потерять эту поддержку во время компиляции, поэтому преимущества ее использования должны перевесить недостаток потери поддержки времени компиляции. Кроме того, вы должны убедиться, что вы можете проверить построение графиков объектов во время запуска приложения или, по крайней мере, в тестовом наборе. Если ваш контейнер DI делает это трудно невозможным, переключение библиотеки или построение графиков объектов вручную может быть лучшим вариантом.

+0

«Использование библиотеки DI позволит вам потерять эту поддержку времени компиляции» на самом деле не действует с появлением кинжала 2 –

+0

@GauravVashisth A ссылка на статью, которая описывает это, была бы полезна. – Steven

+0

Вот некоторые http://google.github.io/dagger/ https://blog.gouline.net/2015/05/04/dagger-2-even-sharper-less-square/ –

Смежные вопросы