МОК, Куда Вы помещаете контейнер?
Как будто вы пытаетесь получить доступ к объекту, который является null. Рассмотрим ниже пример:
TypeA objA;
. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException, что имеет смысл.
См. Также этот пример:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
6 ответов
Основное преимущество Внедрения зависимости, по крайней мере, в моих приложениях, является способностью записать код, который является агностиком контекста. С той точки зрения Ваше второе решение кажется, что действительно ниспровергает DI преимущества, мог давать Вам. Если 'объект бога' представляет различные интерфейсы каждому классу, который ссылается на него, это не могло бы быть слишком злым. Но если Вы пошли, который далеко я не вижу, почему Вы не берете все это путь к обручу.
Пример: Ваш объект Бога имеет getFoo () метод и getBar () метод. Возразите потребностям Нечто, возразите, что B нужна Панель. Если справедливые потребности одно Нечто, Нечто должно быть введено непосредственно в A, и A не должен знать о Боге вообще. Но если потребности продолжать создавать Foos, давая ссылка на Бога в значительной степени неизбежна. Но можно защитить себя от ущерба, нанесенного путем раздавания Бога путем сужения типа ссылки на Бога. Если Вы заставляете Бога реализовать FooFactory и дать ссылку на реализованный FooFactory ей-Богу, можно все еще записать код в нейтральным в отношении контекста способом. Это улучшает возможности для повторного использования кода, и оно увеличивает Вашу уверенность, что изменение в Боге не вызовет неожиданные побочные эффекты. Например, можно быть уверены при удалении getBar () от Бога, которого не повредит класс A.
, НО... если Вы собираетесь иметь все те интерфейсы так или иначе, Вы - вероятно, более обеспеченные пишущие специальные классы фабрики и соединяющий все Ваши объекты проводом вместе, включенные фабрики, в контейнере, вместо того, чтобы обернуть контейнер вообще. Контейнер может все еще настроить фабрики.
Никогда никогда не используйте статические классы как IoC.Container. Твердость или ContainerFactory. GetContainer!
Это делает код более сложным, тяжелее для тестирования, чтобы поддержать, к повторному использованию и читать.
Обычно любой единственный компонент или сервис имеют только одну единственную точку инжекции - это - конструктор (с дополнительными свойствами). И обычно Ваши компоненты или классы обслуживания никогда не должны знать о существовании такой вещи как контейнер.
, Если Ваши компоненты действительно должны иметь динамическое разрешение внутри (т.е. разрешение политики обработки исключений или рабочего процесса, на основе имени), то я рекомендую рассмотреть кредитование полномочия МОК через высоко определенных поставщиков
Я рекомендовал бы проверить мини-сериал Nick Blumhardt на это.
В то время как я ценю явность созданных фабрик "цели" и даже давй использовать их сам, это чувствует себя подобно запаху кода в моих собственных проектах, потому что открытый интерфейс (мало "я") продолжает изменяться с новой фабрикой и/или новым методом GetX для каждой реализации. После чтения Jeremy Miller время для Разрядки Контейнера МОК , я подозреваю дженерики, и введение самого контейнера является способом пойти.
я обернул бы Ninject, StructureMap или Виндзор в некотором интерфейсе IServiceLocator как тот, предложенный в статье Jeremy. Тогда имейте контейнерную фабрику, которая просто возвращает IServiceLocator куда угодно в Вашем коде, даже в циклах, как Вы первоначально предположили.
IServiceLocator container = ContainerFactory.GetContainer();
while( keepLooping )
{
IExample example = container.GetInstance<IExample>();
keepLooping = example.DoWork();
}
Ваша контейнерная фабрика может всегда возвращать тот же экземпляр, можно подкачать платформы МОК, безотносительно.
Как следование [за 110] @flipdoubt
, Если Вы действительно заканчиваете тем, что использовали сервисный шаблон типа локатора, можно хотеть проверить http://www.codeplex.com/CommonServiceLocator . Это имеет некоторую привязку в наличии для нескольких популярных платформ МОК (Виндзор, structuremap), который мог бы быть полезным.
Удача.
Я рекомендовал бы в этом случае с помощью фабрик со строгим контролем типов, как Вы упомянули, который введен. Те фабрики могут обернуть контейнер, но могут позволить передавать в дополнительном контексте и сделать дополнительную обработку. Например, Создавание на OrderFactory могло принять контекстные параметры.
Имеющие статические зависимости от универсального сервисного локатора являются плохой идеей, поскольку Вы освобождаете намерение и контекст. Когда МОК создает экземпляр, он может обеспечить корректные зависимости на основе хоста факторов, такие как proifle, контекст, и т.д. поскольку он имеет большое изображение.
CommonServiceLocator не с этой целью, хотя можно было бы испытать желание использовать его. Основная цель для CommonServiceLocator для приложений / платформы, которые хотят быть перекрестным совместимым контейнером МОК. Однако приложения, что использование должно только назвать локатор оптимально однажды для создания иерархии компонентов и их зависимостей. Это никогда нельзя непосредственно называть снова. Если бы у нас был некоторый способ осуществить это, то мы имели бы. В Призме ( http://www.microsoft.com/compositewpf ) мы представили IContainerFacade для создания модулей. Это - сервисный локатор хотя низкий уровень один. Ретроспективно мы, вероятно, должны были создать ModuleFactory или что-то и использовать IContianerFacade для овладевания им, и затем использовать ту твердость модули по сравнению с движением к Фасаду непосредственно. Непредусмотрительность равняется 20 / 20. Это - низкий уровень достаточно, хотя это это действительно не влияет на вещи.
На CSL, Мы боролись с именованием, потому что это могло бы привести к беспорядку. В конце мы выбрали CSL, потому что технически интерфейс не сделал для Вас, чтобы сделать DI.