Структура инъекции зависимостей для какао? [закрытый]
Interface Builder можно использовать для базовой инъекции зависимостей в приложении Cocoa, но кто-нибудь знает о более полных фреймворках инъекции зависимостей для Objective-C/Cocoa, когда вы не хотите создавать экземпляры объектов в файле NIB?
Edit
чтобы уточнить, я признаю, что IB может использоваться для базового DI, но я ищу фреймворк с более полной функциональностью, включая отдельные производственные и тестовые конфигурации, по следующим направлениям Заводной или пружины.
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 и пример приложения
- API docs:http://www.typhoonframework.org/docs/latest/api/
- у нас есть хороший пример приложения:https://github.com/jasperblues/Typhoon-example
Контроль Качества:
мы также имеем надежную систему контроля качества.
- каждая фиксация запускает серию регрессионные тесты
- мы поддерживаем высокий охват теста.
вам не нужно создавать экземпляр объекта в файле 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, думал, что детали отличаются и от следующего, я не вижу, можно ли определить константы в категории, хотя поля-члены не могут.