1. дома
  2. Вопрос и ответ
  3. Зависимость впрыска для какао?

Зависимость впрыска для какао?

2008-11-21 2 views
52

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

Редактировать

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

источник

2008-11-21 Barry Wark

+2

заказ из www.typhoonframework.org – 2013-02-20 03:36:10

+1

А вот еще один https://github.com/railsware/BloodMagic – AlexDenisov 2013-11-17 11:52:24

+0

Java, безусловно, по-прежнему считается поздним связыванием языка.Хотя он использует диспетчер типа vtable, например C++, благодаря наличию виртуальной машины и системы загрузчика классов, все же возможен перехват методов во время выполнения. Этот подход несколько более громоздкий, чем обмен сообщениями (цель-с), и требует более сложного инструментария, чтобы упростить его использование - такие вещи, как динамические прокси-серверы JSDK, cglib/asm или агент JVM. Это позволяет использовать такие функции, как AOP или «управляемые объекты» (данные спящего/ядра), но имеет мало общего с DI. Я не думаю, что * * java static - требует DI, Objective-C dynamic '*. – 2015-04-23 02:13:02

ответ

11

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

Вот некоторые ссылки, которые, надеюсь, дадут вам пример кода для выполнения аналогичных действий в Objective C. С помощью категорий вы можете существенно изменить поведение любого класса во время выполнения. См. Mac Developer Tips – Objective-C: Categories и Cocoa API docs on categories. По существу вам не нужно какое-то центральное место, чтобы запросить «вещь, которая делает x», которая настраивается, потому что вы можете просто создать экземпляр TheThingThatDoesX напрямую, и если что-то еще нужно изменить/подключить к такому поведению, он может использовать категории.

источник

2009-01-29 02:57:42 Otto

+4

Я думаю, это говорит о том, что Брэд Кокс, дизайнер Objective-C, провел свою жизнь, работая над свободным соединением и повторным использованием программного обеспечения. Динамические возможности Objective-C существуют для решения проблем, решаемых DI для статических языков. http://ieeexplore.ieee.org/iel2/190/267/00004852.pdf?arnumber=4852 – Paul 2009-01-29 03:19:36

+0

Это также говорит о том, что этот пост переполнения стека теперь является лучшим результатом Google для «цели инъекции зависимостей-c» и «инъекции зависимостей» какао". – Otto 2009-01-29 19:41:09

4

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

источник

2008-11-21 19:30:26

+0

Но как насчет инъекции зависимостей для объектов, которые не являются владельцем nib? Я могу создать экземпляр их в банке и, таким образом, использовать IB для инъекций зависимостей, но это не очень масштабируемое решение (файл nib быстро становится громоздким). – 2008-11-21 21:45:36

+0

Вы говорите «Файл Nib», как если бы был только один. У вас может быть столько файлов nib, сколько вам нравится, что совсем не громоздко. Для того, что нить не должна иметь владельца, вы можете поместить любые объекты, которые вам нравятся, в NIB без владельца и вырвать их вручную после загрузки файла NIB. – 2008-11-21 21:56:09

+0

Я думаю, что я немного отслеживал обсуждение, упоминая IB. Я ищу что-то по линии Весны или Гроуви. – 2009-01-08 00:04:39

-2

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

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

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

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

источник

2009-01-27 19:58:30 Rolf

+0

Нет, на самом деле, я ищу библиотеку DI. – 2009-01-28 04:32:49

-2

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

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

Я рад, что вас исправили.

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

objective-c categories

источник

2009-10-29 15:49:33 groovePupil

-1

ли какой-либо смотрел на Associative References особенность Mac OS X 10.6?

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

Manfred

источник

2010-02-19 09:00:35 Manfred

1

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

источник

2010-10-06 12:18:28 zoul

-1

Интерфейс Builder не делает никакой инъекции зависимостей. Это не нужно. Интерфейс Builder сериализует объекты. Когда нить «проснулся» (он же открыт), «никаких зависимостей» не существует - есть только свойства, которые нужно установить. Очень, очень просто. Открытие наконечника основывается исключительно на протоколе NSCoding и кодировании ключевого значения.

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

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

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

источник

2010-12-10 15:58:40 Bored

16

Я выйду на конечность и поговорю об этом. Включение зависимостей, как описано в верхнем ответе, не касается основной проблемы, с которой сталкиваются те, кто пытается ее использовать. Нам нужны средства разработки, в которых компонент A напрямую не создает экземпляр или не ссылается на компонент B. Компонент A связан протоколом с компонентом B и вообще не ссылается на компонент A. Это позволяет заменить компонент B в любое время без касаясь компонента A. Я проголосовал, но я буду исследовать ваши ссылки, поскольку кажется, что есть несколько, которые согласны с вами. Я не пытаюсь обсуждать, просто хочу учиться. Я хотел бы больше узнать о подходе «нет, вам не нужно».

источник

2011-06-28 18:14:05 Cliff

5

Typhoon

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

В Typhoon-website перечислены ключевые особенности. Краткое резюме:

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Каждый коммит запускает серию regression tests
  • Мы поддерживаем высокий уровень охвата тестирования.

источник

2012-12-30 07:14:40

 Смежные вопросы

  • Нет связанных вопросов^_^