Зависимость инъекций против глобальной фабрики

Question

Почему люди по умолчанию используют DI против глобальной фабрики с хэш-картой, которая отображает интерфейсы / рефераты в классы? Казалось бы, это более высокопроизводительное решение проблемы нет?

Все вещи, упомянутые до сих пор в этой теме, могут быть предоставлены глобальной фабрикой с помощью метода, подобного:

TestGlobalFactory implements GlobalFactoryI
ProductionGlobalFactory implements GlobalFactoryI //configures classes to interfaces

protected GlobalFactoryI gf=GlobalFactoryFactory.getInstance(); //only singleton used in app, specifies which GlobalFactory to use

protected SportsCarI mySportsCar=gf.new("sportsCarI",constructorVar1,constructorVar2);

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

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

artima.com / forums / flat.jsp? Forum = 106 & thread = 238700

Независимо от DI, это лучший подход, так как он имеет контейнеры, написанные для указания, какая реализация принадлежит какому классу. С Service Locator фактически нужно было бы сделать gf.new ("thisClass", "sportsCarI", constructor1)

Answer 1

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

Answer 2

Потому что вы получаете намного больше с Spring. Spring управляет жизненным циклом своих bean-компонентов, в дополнение к экземплярам кэширования в соответствии с заданной пользователем областью для bean-компонентов (например, prototype, singleton и т. Д.). Также обратите внимание, что DI Spring связан с его «инверсией управления», поэтому вещи не жестко запрограммированы непосредственно в приложении (если не учитывать код конфигурации).