Зависимость от инъекций?

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

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

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

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

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

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

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

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

Also, I'd feel much better if it were a part of the language I was using.

К вашему сведению, в составе 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 определяет возвращаемые реализации служб?

В папке вашего проекта создайте папку с именем МЕТА-ИНФ / услуги и создайте файл с именем dependencyinjection.FooService. Этот файл содержит строку, указывающую на реализацию службы. В этом случае: dependencecyinjection.FooImpl

Пока об этом мало что известно.

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

i = GetServiceOrInterfaceOrObject(...)

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

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

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