Interface Builder 可用于 Cocoa 应用程序中的基本依赖注入,但是当您不想在 NIB 文件中实例化对象时,是否有人知道用于 Objective-C/Cocoa 的更完整的依赖注入框架?
编辑
澄清一下,我承认 IB 可用于基本 DI,但我正在寻找一个功能更完整的框架,包括单独的生产和测试配置,类似于 Groovy 或 Springs。
Interface Builder 可用于 Cocoa 应用程序中的基本依赖注入,但是当您不想在 NIB 文件中实例化对象时,是否有人知道用于 Objective-C/Cocoa 的更完整的依赖注入框架?
编辑
澄清一下,我承认 IB 可用于基本 DI,但我正在寻找一个功能更完整的框架,包括单独的生产和测试配置,类似于 Groovy 或 Springs。
AtomicObject 的反对意见。它是按照 Guice 的形象塑造的。
我会冒险出去谈谈这个。最佳答案所描述的依赖注入并没有解决那些寻求使用它的人所面临的核心问题。我们想要一种开发方式,其中组件 A 不直接实例化或引用组件 B。组件 A 由协议绑定到组件 B,并且根本不被组件 A 引用。这允许组件 B 在任何时候被替换,而不会永远感人的 A 部分。我投了反对票,但我会研究你的参考资料,因为似乎有一些人同意你的观点。我不是想辩论,只是想学习。我想更多地了解“不,你不需要这样做”的方法。
我想您会发现在诸如 Objective C、Ruby、Lisp 等后期绑定语言中不需要它。就像 Jamis 透露他在尝试构建 needle 时走上一条过于复杂的道路一样,重新审视了 Ruby-Net::SSH的 DI 框架。
这里有一些链接,有望为您提供一些示例代码,以便在 Objective C 中执行类似的操作。使用类别,您基本上可以在运行时更改任何类的行为。请参阅Mac 开发人员提示 – Objective-C:类别和类别上的 Cocoa API 文档。本质上,您不需要某个中心位置来请求可配置的“执行 x 的事情”,因为您可以直接实例化 TheThingThatDoesX,如果有其他东西需要更改/挂钩到该行为,它可以使用类别。
台风
差不多一年前,我发布了:https ://github.com/typhoon-framework/Typhoon
Typhoon 网站列出了主要功能。快速总结:
非侵入性的。不需要宏或 XML。使用强大的 Objective-C 运行时方法。
使同一基类或协议的多个配置变得容易。
没有魔法字符串 - 支持 IDE 重构、代码完成和编译时检查。
支持注入视图控制器和故事板集成。
支持初始化程序和属性注入,以及生命周期管理。
强大的内存管理功能。提供预配置的对象,没有单例的内存开销。
对循环依赖的出色支持。
倾斜。它的占用空间非常小,因此适用于 CPU 和内存受限的设备。
久经考验 - 用于各种 Appstore 特色应用程序
一个国际分布的核心团队(我们甚至监控 StackOverflow),因此对您的任何问题的支持都不会太远:)
API 文档和示例应用程序
质量控制:
我们还保持着强大的质量控制系统。
您不必在 NIB 文件中实例化对象。如果您将文件的所有者设置为对象的类,然后将视图/窗口/任何内容中的内容链接到该类,则可以通过手动加载 nib 文件在运行时将对象设置为所有者。这样你就可以拥有一个对象的动态实例,它仍然可以正确注入依赖项。
Objective-IOC 的依赖注入实现怎么样
ObjectivePim 呢? 目标Pim
我写了一个非常简单的 DI 容器,代码在GitHub 上。它只能做最基本的事情,即。发现一个对象的依赖关系并使用其他给定的对象来满足它们。我发现要在现实世界的应用程序中使用,代码非常简单,而且很有趣。
有没有看过Mac OS X 10.6的关联引用功能?
我相信有了这个,就有可能构建或已经拥有类似于 DI 的东西。据我所知,对象中需要的任何引用都必须使用 objc_getAssociatedObject() 手动获取。
曼弗雷德
Interface Builder 不执行任何依赖注入。它不需要。Interface Builder 序列化对象。当笔尖“唤醒”(又名打开)时,没有“依赖关系”需要解决——只有要设置的属性。非常非常简单。打开 nib 仅依赖于 NSCoding 协议和键值编码。
依赖注入,在最好的情况下几乎是一个临时项目,或者充其量是独立设计的组件之间的通用粘合层,在编写良好的 Objective-C 代码中是没有用的。您正在要求一个您不需要的工具。
在 Objective-C 中,需要匿名服务的软件声明了一个协议。然后服务采用此协议。客户端将服务加载为动态插件。另一方面,如果服务器是在客户端之前编写的,那么只需编写一个新的插件来使现有接口适应协议。与尝试定义中间数据驱动系统以在运行时“发现”(请)接口相比,这需要更少的工作,并且更直接。
DI 的最大秘密在于它是一种用 XML 而不是本地语言编写代码的方式,这对每个人来说不是很明显吗?我真的很想听听一个很好的论点,说明 XML 如何在某种程度上是一种比真正的编程语言更好的编程语言。这没有任何意义。
我整天都在使用 Spring,并且检查了 Groovy。我绝不是 XCode/Cocoa 专家,但 IB 只做了一些依赖注入,而 Groovy 甚至没有真正声称这样做。
我认为您不是在寻找 DI,而是在寻找一组编译良好的集成库,这样您就不必输入其他人也输入过的大量代码。我认为 Cocoa 没有类似 Spring 的框架,因为出于某种原因,人们倾向于将“开源”视为“不依赖于平台”,因此 Cocoa 有点被冷落了。
不过,根据您的需要,有一些可用于 Cocoa 的不错的免费开源库,所有这些都列在 CocoaDev 的一个不错的列表中。
我知道这不是春天,但我希望它有所帮助。
DI 是需要动态绑定的运行时执行环境的属性。我对 Obj-C 和 Cocoa 很陌生,所以我可能会说话不顺。除非我遗漏了什么,否则我看不出如何实现 DI,除非通过解释 Obj C 而不是编译它,或者通过修改运行时环境。
我怀疑 IB 类似 DI 的行为是因为有一个特定于域的运行时环境与使用它构建的应用程序相关联。
不过我很高兴得到纠正。
类别似乎是 mixin 的实现,允许将方法动态分派给委托。相当酷,类似于Java的接口概念,认为细节不同,从以下,我看不出是否可以在类别中定义常量,尽管成员字段不能。