Структура инъекции зависимостей для какао? [закрытый]


Interface Builder можно использовать для базовой инъекции зависимостей в приложении Cocoa, но кто-нибудь знает о более полных фреймворках инъекции зависимостей для Objective-C/Cocoa, когда вы не хотите создавать экземпляры объектов в файле NIB?

Edit

чтобы уточнить, я признаю, что IB может использоваться для базового DI, но я ищу фреймворк с более полной функциональностью, включая отдельные производственные и тестовые конфигурации, по следующим направлениям Заводной или пружины.

12 52

12 ответов:

Я думаю, вы обнаружите, что вам это не нужно в поздних языках привязки, таких как Objective C, Ruby, Lisp и так далее. Как и откровение Джеймиса, что он шел по слишком сложному пути, когда он пытался построить иглу, каркас DI для Ruby - Net:: SSH revisited.

вот некоторые ссылки, которые, надеюсь, дадут вам пример кода для выполнения аналогичных действий в Objective C. С категориями вы можете существенно изменить поведение любого класса во время выполнения. Смотрите Mac Советы Для Разработчиков-Цель-C: Категории и Cocoa API docs по категориям. По сути, вам не нужно какое-то центральное место, чтобы попросить "вещь, которая делает x", которая настраивается, потому что вы можете просто создать экземпляр thethingthatdoesx напрямую, и если что-то еще нужно изменить/подключить к этому поведению, он может использовать категории.

возражение по AtomicObject. Он вылеплен по образу Guice.

Я выйду на ветку и поговорю об этом. Инъекция зависимостей, описанная в верхнем ответе, не решает основную проблему, с которой сталкиваются те, кто пытается ее использовать. Мы хотели бы средство разработки, где компонент A непосредственно не создает экземпляр или не ссылается на компонент B. компонент a связан протоколом с компонентом B и вообще не ссылается на компонент A. Это позволяет заменять компонент B в любое время, никогда не касаясь компонента A. Я проголосовал, но я буду исследовать ваш ссылки как кажется есть несколько, Кто согласен с вами. Я не пытаюсь спорить, просто хочу узнать. Я хотел бы понять больше о подходе "нет, вам не нужно этого делать".

Тайфун

почти год назад я выпустил:https://github.com/typhoon-framework/Typhoon

на Тайфун-сайт список ключевых функций. Краткое описание:

  • неинвазивная. Никаких макросов или XML не требуется. Использует мощный подход к времени выполнения Objective-C.

  • делает его легким иметь множественные конфигурации тот же базовый класс или протокол.

  • нет волшебных строк-поддерживает рефакторинг IDE, завершение кода и проверку времени компиляции.

  • поддерживает инжекцию контроллеров вида и интеграцию раскадровки.

  • поддерживает как инициализатор, так и инъекцию свойств, а также управление жизненным циклом.

  • мощные функции управления памятью. Предоставляет предварительно настроенные объекты, без памяти над головой одиночки.

  • отличная поддержка круговых зависимостей.

  • худой. Он имеет очень низкий след ноги, поэтому соотвествующий для приборов ограничиваемых К. П. У. и памятью.

  • Battle-tested-используется во всех видах приложений Appstore-featured

  • международная распределенная основная команда (мы даже контролируем StackOverflow), поэтому поддержка любого из ваших вопросов никогда не бывает далеко :)

API Docs и пример приложения

Контроль Качества:

мы также имеем надежную систему контроля качества.

вам не нужно создавать экземпляр объекта в файле NIB. Если вы установите владельца файла в класс вашего объекта, а затем свяжете вещи в представлении/окне/независимо от этого, вы можете установить свой объект в качестве владельца во время выполнения, загрузив файл nib вручную. Таким образом, вы можете иметь динамический экземпляр объекта, который все еще получает зависимости, введенные правильно.

Как насчет реализации инъекции dependecy в цель-МОК

Как насчет ObjectivePim? ObjectivePim

Я написал очень простой контейнер DI, код находится на GitHub. Он может делать только голые основы, т. е. откройте зависимости объекта и удовлетворите их, используя другие заданные объекты. Я обнаружил, что для использования в реальных приложениях код очень прост, и его весело взломать.

кто-нибудь посмотрел на Ассоциативных Ссылок особенность Mac OS X 10.6?

Я считаю, что с этим можно было бы построить или уже иметь что-то похожее на DI. Насколько я видел, однако любая ссылка, которая необходима в объекте, должна быть извлечена вручную с помощью objc_getAssociatedObject().

Манфред

Interface Builder не выполняет инъекции зависимостей. В этом нет необходимости. Построитель интерфейса сериализует объекты. Когда перо " пробуждено "(он же открыт), нет никаких" зависимостей " для разрешения-есть только свойства для установки. Очень, очень просто. Открытие наконечника зависит исключительно от протокола NSCoding и кодирования ключевых значений.

инъекция зависимостей, в значительной степени проект make-work в лучшем случае или в лучшем случае обобщенный клеевой слой между разработанными компонентами независимо от этого, не имеет смысла в хорошо написанном коде Objective-C. Вы просите инструмент, который вам не нужен.

в Objective-C программное обеспечение, требующее анонимной службы, объявляет протокол. Затем службы принимают этот протокол. Клиенты загружают сервисы как динамические Плагины. С другой стороны, если сервер был написан до клиента, это просто вопрос написания нового плагина, который адаптирует существующий интерфейс к протоколу. Это меньше работы, и более простой чем пытаться определить промежуточную управляемую данными систему для "обнаружения" (пожалуйста) интерфейса во время выполнения.

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

Я работаю с весной весь день, и я проверил Groovy. Я ни в коем случае не эксперт XCode/Cocoa, но IB делает только некоторую инъекцию зависимости, которую Groovy даже не утверждает, что делает.

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

в зависимости от ваших потребностей, хотя, есть некоторые хорошие бесплатные библиотеки с открытым исходным кодом, доступные для Cocoa, все перечисленные на CocoaDev в хороший список.

Я знаю, что это не весна, но я надеюсь, что это помогает.

Ди является свойством времени выполнения, окружающей среде, требующих динамического связывания. Я очень новичок в Obj-C и Cocoa, поэтому я могу говорить вне очереди. Если я чего-то не упускаю, я не вижу, как можно реализовать DI, кроме как интерпретируя Obj C, а не компилируя его или изменяя среду выполнения.

Я подозреваю, что DI подобное поведение IB связано с тем, что существует доменная среда выполнения, связанная с приложениями, которые построены с ней.

Я но я рад, что меня поправили.

категории, по-видимому, являются реализацией mixin, позволяя динамическую отправку методов делегату. Довольно круто и похоже на концепцию интерфейса Java, думал, что детали отличаются и от следующего, я не вижу, можно ли определить константы в категории, хотя поля-члены не могут.

цель-категории c