Я знаю, что этот вопрос старый, но я хотел бы добавить свои пять центов,
Я думаю, что внедрение зависимостей (DI) во многом похоже на конфигурируемый Factory Pattern (FP), и в этом смысле все, что вы можете сделать с DI, вы сможете сделать с такой фабрикой.
На самом деле, если вы используете Spring, например, у вас есть возможность автоматического подключения ресурсов (DI) или делать что-то вроде этого:
MyBean mb = ctx.getBean("myBean");
А затем используйте этот экземпляр 'mb', чтобы сделать что-нибудь. Разве это не вызов фабрике, которая вернет вам экземпляр?
Единственное реальное различие, которое я замечаю между большинством примеров FP, это то, что вы можете настроить, что «myBean» находится в xml или в другом классе, и фреймворк будет работать как фабрика, но в остальном это то же самое и, конечно, у вас может быть Фабрика, которая читает файл конфигурации или получает реализацию по мере необходимости.
И если вы спросите меня о моем мнении (и я знаю, что вы этого не сделали), я считаю, что DI делает то же самое, но только добавляет сложности в разработку, почему?
Ну, во-первых, чтобы вы знали, какая реализация используется для любого bean-компонента, который вы автоматически связываете с DI, вам нужно перейти к самой конфигурации.
но ... как насчет того обещания, что вам не нужно будет знать реализацию объекта, который вы используете? Пфф! шутки в сторону? когда вы используете такой подход ... разве вы не то же самое, что пишет реализацию? и даже если вы этого не сделаете, разве вы почти все время смотрите на то, как реализация делает то, что должна делать ??
и, наконец, не имеет значения, сколько DI-фреймворк обещает , что вы будете строить из него вещи отделенные без каких-либо зависимостей от их классов, если вы используете фреймворк, вы строите все вокруг, , если вам нужно изменить подход или фреймворк, это не будет легкой задачей ... КОГДА-ЛИБО! ... но, поскольку вы строите все вокруг этого Если вы не будете беспокоиться о том, какое решение лучше всего подходит для вашего бизнеса, вы столкнетесь с серьезной проблемой при этом.
Фактически, единственное реальное бизнес-приложение для подхода FP или DI, которое я вижу, это если вам нужно изменить реализации, используемые в runtime , но по крайней мере известные мне фреймворки не позволяют чтобы сделать это, вы должны оставить все идеально в конфигурации во время разработки и, если вам нужно, использовать другой подход.
Итак, если у меня есть класс, который по-разному работает в двух областях в одном приложении (скажем, в двух компаниях холдинга), я должен сконфигурировать среду для создания двух разных bean-компонентов и адаптировать свой код для использования каждого. Разве это не то же самое, что если бы я просто написал что-то вроде этого:
MyBean mb = MyBeanForEntreprise1(); //In the classes of the first enterprise
MyBean mb = MyBeanForEntreprise2(); //In the classes of the second enterprise
так же, как это:
@Autowired MyBean mbForEnterprise1; //In the classes of the first enterprise
@Autowired MyBean mbForEnterprise2; //In the classes of the second enterprise
И это:
MyBean mb = (MyBean)MyFactory.get("myBeanForEntreprise1"); //In the classes of the first enterprise
MyBean mb = (MyBean)MyFactory.get("myBeanForEntreprise2"); //In the classes of the second enterprise
В любом случае вам придется что-то изменить в своем приложении, будь то классы или файлы конфигурации, но вам придется сделать это заново, развернув его.
Не было бы неплохо сделать что-то вроде этого:
MyBean mb = (MyBean)MyFactory.get("mb");
И таким образом, вы устанавливаете код фабрики, чтобы получить правильную реализацию во время выполнения в зависимости от зарегистрированного пользователя предприятия ?? Теперь это будет полезно. Вы можете просто добавить новый jar с новыми классами и установить правила, возможно, даже во время выполнения (или добавить новый файл конфигурации, если вы оставите эту опцию открытой), без изменений в существующих классах. Это будет динамическая фабрика!
Разве это не было бы более полезным, чем писать две конфигурации для каждого предприятия и, возможно, даже иметь два разных приложения для каждого ??
Вы можете сказать мне, что мне вообще не нужно переключаться во время выполнения, поэтому я настраиваю приложение, и, если я наследую класс или использую другую реализацию, я просто изменяю конфигурацию и повторно развертываю. Хорошо, это также может быть сделано с завода. И, честно говоря, сколько раз вы делаете это? возможно, только когда у вас есть приложение, которое будет использоваться где-то еще в вашей компании, и вы собираетесь передать код другой команде, и они будут делать такие вещи. Но эй, это также можно сделать с фабрикой, и было бы еще лучше с динамической фабрикой !!
В любом случае, секция комментариев открыта для вас, чтобы убить меня.