Я знаю, что этот вопрос старый, но я хотел бы добавить свои пять центов,
Я думаю, что внедрение зависимостей (DI) во многом похоже на конфигурируемый Factory Pattern (FP), и в этом смысле все, что вы можете сделать с DI, вы сможете сделать с такой фабрикой.
На самом деле, если вы используете Spring, например, у вас есть возможность автоматического подключения ресурсов (DI) или делать что-то вроде этого:
MyBean mb = ctx.getBean("myBean");
А затем используйте этот экземпляр 'mb', чтобы сделать что-нибудь. Разве это не вызов фабрике, которая вернет вам экземпляр?
Единственное реальное различие, которое я замечаю между большинством примеров FP, заключается в том, что вы можете настроить, что «myBean» находится в xml или в другом классе, и фреймворк будет работать как фабрика, но в остальном это то же самое, и вы может иметь Фабрику, которая читает конфигурационный файл или получает реализацию по мере необходимости.
И если вы спросите меня о моем мнении (и я знаю, что вы этого не сделали), я считаю, что DI делает то же самое, но просто добавляет сложности в разработку, почему?
Ну, во-первых, чтобы вы знали, какая реализация используется для любого bean-компонента, который вы автоматически связываете с DI, вы должны перейти к самой конфигурации.
но ... как насчет того обещания, что вам не нужно будет знать реализацию объекта, который вы используете? Пфф! шутки в сторону? когда вы используете такой подход ... разве вы не то же самое, что пишет реализацию? и даже если вы этого не сделаете, разве вы почти все время смотрите на то, как реализация делает то, что должна делать ??
и, наконец, не имеет значения, насколько DI-фреймворк обещает вам, что вы будете строить вещи, отделенные от него, без каких-либо зависимостей от их классов, если вы используете фреймворк, вы создаете все вокруг, если вам нужно изменить подход или рамки это не будет легкой задачей ... КОГДА-ЛИБО! ... но, поскольку вы строите все вокруг этой конкретной структуры, вместо того чтобы беспокоиться о том, какое решение лучше всего подходит для вашего бизнеса, вы столкнетесь с серьезной проблемой при этом.
Фактически, единственное реальное бизнес-приложение для подхода FP или DI, которое я вижу, - это если вам нужно изменить реализации, используемые во время выполнения , но, по крайней мере, известные мне фреймворки не позволяют вам это делать, вы должны оставить все идеально в конфигурации во время разработки, и если вам нужно, используйте другой подход.
Итак, если у меня есть класс, который по-разному работает в двух областях в одном и том же приложении (скажем, в двух компаниях холдинга), я должен сконфигурировать среду для создания двух разных 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 с новыми классами и установить правила, возможно, даже во время выполнения (или добавить новый файл конфигурации, если вы оставите эту опцию открытой), без изменений в существующих классах. Это будет динамическая фабрика!
Разве это не было бы более полезным, чем написать две конфигурации для каждого предприятия и, может быть, даже иметь два разных приложения для каждого?
Вы можете сказать мне, что мне не нужно выполнять переключение во время выполнения, поэтому я настраиваю приложение, и, если я наследую класс или использую другую реализацию, я просто изменяю конфигурацию и повторно развертываю. Хорошо, это также может быть сделано с завода. И, честно говоря, сколько раз вы делаете это? возможно, только когда у вас есть приложение, которое будет использоваться где-то еще в вашей компании, и вы собираетесь передать код другой команде, и они будут делать такие вещи. Но эй, это также можно сделать с фабрикой, и было бы еще лучше с динамической фабрикой !!
Во всяком случае, раздел комментариев, если вы открыты, чтобы убить меня.
