Зависимость от инъекционной зависимости? - PullRequest
12 голосов
/ 04 сентября 2008

Есть ли обратная сторона? Я чувствую себя почти зависимым от этого сейчас. Всякий раз, когда проект выходит за рамки определенного размера, почти чувствуется аллергическая реакция на стандартные шаблоны и сразу же подключается к нему с помощью структуры внедрения зависимостей.

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

Кроме того, я бы почувствовал себя намного лучше, если бы это было частью языка, который я использовал. Хотя, по крайней мере для Java, есть пара очень легких библиотек, которые довольно хороши.

Мысли? Плохой опыт? Или просто перестать беспокоиться об этом?


[EDIT] Re: описание самого внедрения зависимостей

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

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

Ответы [ 9 ]

13 голосов
/ 04 сентября 2008

Я попытался описать некоторые возможные недостатки в сообщении блога здесь: http://kevin -berridge.blogspot.com / 2008/06 / ioc-and-di-сложно. *

5 голосов
/ 12 февраля 2011

У меня проблема с DI - та же проблема, что и с COM, и с любым кодом, который выглядит примерно так:

i = GetServiceOrInterfaceOrObject(...)

Проблема в том, что такую ​​систему невозможно понять из кода. Где-то должна быть документация [где-то еще], определяющая, какая служба / интерфейс / объект может запрашиваться службой / интерфейсом / объектом X. Эта документация должна не только поддерживаться, но и быть доступной так же легко, как и источник.

Если документ не очень хорошо написан, часто все еще не легко увидеть отношения между объектами. Иногда отношения носят временный характер, что делает их еще сложнее обнаружить.

Мне нравится принцип KISS, и я твердо верю в использование правильного инструмента для работы. Если выгода DI для данного проекта перевешивает необходимость написания понятного кода, чем использовать его.

4 голосов
/ 04 сентября 2008

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

К вашему сведению, в JDK 6 есть очень простая и функциональная инъекция зависимостей. Если вам нужна легкая и простая инъекция зависимостей, используйте ее.

Используя ServiceLoader класс, вы можете запросить услугу (или множество реализаций службы) на основе класса:

 package dependecyinjection;  
 import java.util.ServiceLoader;  

 public abstract class FooService {  

     public static FooService getService() {  
         ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);  

         for (FooService service : loader) {  
             return provider;  
         }  

         throw new Exception ("No service");  
     }  

     public abstract int fooOperation();  

 }  

 package dependecyinjection;  
 public class FooImpl extends FooService {  
     @Override  
     public int fooOperation() {  
         return 2;  
     }  
 }  

Как ServiceLoader определяет возвращаемые реализации служб?

В папке проекта создайте папку с именем META-INF / services и создайте файл с именем dependencyinjection.FooService . Этот файл содержит строку, указывающую на реализацию сервиса. В этом случае: dependecyinjection.FooImpl

Это пока широко не известно.

4 голосов
/ 04 сентября 2008

Я большой любитель в IO, однако я видел несколько проектов с огромными файлами конфигурации xml, которые никто не понимает. Так что остерегайтесь программирования в XML.

3 голосов
/ 04 сентября 2008

Просто перестань беспокоиться об этом. По моему мнению, со временем методы IoC станут второй натурой большинства разработчиков. Я пытаюсь рассказать об этом разработчикам здесь, и мне трудно донести эту мысль, потому что она кажется настолько неестественной для того, как мы всегда что-то делали ... что, как оказалось, было неверным. Кроме того, разработчикам, как новичкам в IoC, так и новичкам в проекте, который я считаю, приходится еще труднее. Они привыкли использовать IDE для отслеживания зависимостей, чтобы получить представление о том, как все это «держится вместе». Эта информация часто записывается в тайный XML.

3 голосов
/ 04 сентября 2008

По моему мнению, основными недостатками являются кривая обучения (как вы указали) и возможность добавления абстракции, чтобы сделать его более трудным для отладки (что также является частью кривой обучения).

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

2 голосов
/ 04 сентября 2008

Не могли бы вы добавить ссылку или две, чтобы объяснить, что такое Dependency Injection для тех из нас, кто играет дома? статья в Википедии интересна, но не очень поучительна.

1 голос
/ 04 сентября 2008

Единственный недостаток, который я могу вспомнить, это незначительное снижение производительности из-за постоянных виртуальных вызовов:)

0 голосов
/ 04 сентября 2008

@ Blorgbeard: http://www.martinfowler.com/articles/injection.html, вероятно, одна из лучших статей на эту тему

...