Cocoa依赖注入框架?[关闭]

我想您会发现在后期的绑定语言中不需要它,比如Objective C、Ruby、Lisp等等。就像Jamis在试图构建Ruby的DI框架Needle时透露的那样,他正走上一条过于复杂的道路。- Net::SSH revisited .

这里有一些链接,希望能给您一些示例代码,以便在目标C中执行类似的操作。对于类别,您基本上可以在运行时更改任何类的行为。见 Mac Developer Tips – Objective-C: Categories 以及 Cocoa API docs on categories . 本质上,你不需要一个中心位置来要求“做X的事情”,这是可配置的,因为你可以直接实例化做X的事情,如果其他事情需要改变/钩住这个行为,它可以使用类别。

objection 原子对象。它被塑造成Guice的形象。

我要冒险出去谈谈这件事。顶级答案所描述的依赖注入并不能解决那些想要使用它的人所面临的核心问题。我们希望有一种开发方法,其中组件A不直接实例化或引用组件B。组件A受组件B的协议约束,完全不被组件A引用。这允许组件B随时被替换,而不接触组件A。我投了反对票,但我将研究您的引用,因为它似乎是少数人同意你的观点。我不想争论,只是想学习。我想了解更多关于“不,你不需要这样做”的方法。

台风

差不多一年前,我发布了: https://github.com/typhoon-framework/Typhoon

这个 Typhoon-website 列出主要功能。快速总结:

• 无创性。不需要宏或XML。使用A powerful Objective-C runtime approach .

• 使具有相同基类或协议的多个配置变得容易。

• 没有魔术字符串-支持IDE重构、代码完成和编译时检查。

• 支持视图控制器和情节提要集成的注入。

• 支持初始值设定项和属性注入,以及生命周期管理。

• 强大的内存管理功能。提供预先配置的对象,而不需要单例的内存开销。

• 对循环依赖性的极好支持。

• 精益。它的占地面积非常小,因此适用于CPU和内存受限的设备。

• 战斗测试-用于各种应用商店特色应用

• 一个国际分布的核心团队(我们甚至监视stackoverflow),因此对您的任何问题的支持永远不会太远:)

API文档和示例应用程序

• API文档: http://www.typhoonframework.org/docs/latest/api/
• 我们有一个很好的示例应用程序: https://github.com/jasperblues/Typhoon-example

质量控制:

我们还保持一个强大的质量控制系统。

• 每次提交都会触发一系列 regression tests
• 我们保持高测试覆盖率。

您不必在NIB文件中实例化对象。如果将文件的所有者设置为对象的类,然后将视图/窗口中的内容链接到该类,则可以在运行时通过手动加载NIB文件将对象设置为所有者。这样,您就可以拥有一个对象的动态实例,它仍然能够正确地注入依赖项。

依赖注入的实现在 Objective-IOC

客观主义呢? ObjectivePim

我写了一个非常简单的DI容器,代码是开的 GitHub . 它只能做一些基本的工作,即发现一个对象的依赖关系,并使用其他给定的对象来满足它们。我发现,要在现实世界的应用程序中使用,代码非常简单,黑客技术也很有趣。

有没有看过 Associative References Mac OS X 10.6的功能?

我相信有了这个,就可以建造或者已经拥有类似于DI的东西。 不过,据我所见,必须使用objc_GetAssociatedObject()手动获取对象中所需的任何引用。

曼弗雷德

接口生成器不执行任何依赖项注入。不需要。接口生成器序列化对象。当一个NIB被“唤醒”(aka opened)时,没有要解析的“依赖关系”——只有属性可以设置。非常非常简单。打开一个NIB完全依赖于nscoding协议和键值编码。

依赖注入,几乎在最好的时候是一个可以工作的项目,或者最好是独立设计的组件之间的通用粘合层,在编写良好的Objective-C代码中是没有用的。你在要求一个你不需要的工具。

在Objective-C中,需要匿名服务的软件声明一个协议。然后服务采用这个协议。客户端将服务作为动态插件加载。另一方面,如果服务器是在客户机之前编写的,那么只需编写一个新的插件,它可以使现有接口适应协议。这比试图在运行时为“发现”(请)一个接口定义一个中间数据驱动系统要简单得多,而且工作更少。

对于每个人来说,DI的最大秘密是它是一种用XML而不是用本机语言编写代码的方法,这一点不是显而易见的吗?我真的很想听到一个很好的论点,那就是XML在某种程度上是一种比真正的编程语言更好的编程语言。这没有任何意义。

我整天和Spring一起工作,我已经检查了groovy。我决不是Xcode/Cocoa专家,但是ib只做了一些依赖注入,而groovy甚至没有真正声称要做。

我认为您不是在寻找DI,而是在寻找一组编译良好的集成库,这样可以避免您键入许多其他人也键入的代码。我认为Cocoa没有类似Spring的框架,因为出于某种原因,人们倾向于将“开源”视为“不依赖平台”,因此Cocoa有点被冷落了。

不过,根据您的需要,有一些很好的免费开放源码库可供Cocoa使用,这些库都列在Cocoadev的 nice list .

我知道这不是春天,但我希望它有帮助。

DI是需要动态绑定的运行时执行环境的属性。我对obj-c和cocoa很陌生,所以我可能会不合时宜地说话。除非我遗漏了一些东西,否则我不知道如何实现DI,除非通过解释obj c而不是编译它,或者通过修改运行时环境。

我怀疑ib类DI的行为是因为有一个特定于域的运行时环境与它所构建的应用程序相关联。

不过,我很高兴被纠正。

类别似乎是mixin的实现,允许将方法动态分派给委托。相当酷,类似Java的接口概念,认为细节不同,从下面,我看不见常数是否可以定义在一个类别,虽然成员字段不能。

objective-c categories