Как выбрать между методами получения зависимостей?

Question

Я видел как минимум три способа получения зависимостей в объекте Java без привязки объекта к созданию зависимости;

Внедрение зависимостей - какая-то инфраструктура внедряет требуемый объект в другой объект на основе внешней конфигурации, например: управляемые компоненты Spring

Поиск зависимостей - класс ищет требуемую зависимость в какой-либо службе каталогов, например: поиск JNDI в контейнере Java EE

Статические заводы - объект в глобальной области действия предоставляет экземпляры по запросу - стандартные API Java SE, похоже, изобилуют этими примерами: java.util.Logger.getLogger (name) , java.util. Calendar.getInstance ()

Какое руководство вы можете дать относительно того, какое из них наиболее подходит для ситуации?

Answer 1

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

Поиск зависимостей по-прежнему требует, чтобы объект знал о службе поиска и ее URL.

Статические фабрики похожи на службы поиска.

Answer 2

Я предпочитаю внедрение зависимостей .

Когда я говорю о DI в Spring Framework, я вижу следующее

1. Поддерживается IDE (проверка ошибок, визуализация).
2. Вы можете настроить другие необходимые вещи, такие как AOP, загрузка свойств, ...
3. У вас есть большие возможности конфигурации - XML, аннотации, JavaConfig
4. Можно использовать также в настольном приложении.

Они перевешивают все негативы, такие как зависимость от другой библиотеки. Почему я должен использовать другой подход?

Answer 3

Это действительно зависит от контекста. Если вы пишете автономный Maths API, вы, возможно, захотите использовать статические фабрики, потому что код будет менее подробным, не требующим настройки и, возможно, более эффективным. Если вам нужно получить доступ / предоставить удаленную зависимость, поиск JNDI / LDAP или обмен сообщениями ESB будет работать хорошо. Для внедрения ваших служб / DAO / источников данных в ваш типичный код корпоративного сервера вам лучше использовать один из распространенных D.I. фреймворки, такие как Google Guice или Spring.

Не существует единого «лучшего» решения в разработке программного обеспечения; это всегда компромисс.