2

我无法理解 Typhoon文档使用的术语。

所以看起来你基本上定义了 aTyphoonAssembly并且它包含了所有的对象。然后创建一个或多个TyphoonDefinition's 来描述如何实例化对象。我假设这些定义是在实现中执行的。但是，这些在文档TyphoonDefinition的Types of Injections部分下。

在使用 Spring 等其他 iOC 容器时，术语注入是指将构建的组件提供给依赖对象的过程，而不是注入到 iOC 容器本身中。

我对文档的理解是错误的，还是使用的术语不同？

4

1 回答 1

3

如果它有助于您将 Typhoon 与 Spring 进行比较，您可以将其TyphoonDefinition视为 Spring bean：构造对象的蓝图，使用初始化程序，以及要调用的任何属性设置器或方法。

像 Spring 一样，您可以提供对另一个组件的引用或注入简单的配置。

同样，像 Spring 一样，您可以选择将相关组件组合在一起。

事实上，Typhoon 的内部模型与 Spring 非常相似，具有后处理器等（创始人——也就是我——是 Spring 框架的贡献者，曾在 SpringSource 工作过一段时间）。不同的是：

  • Typhoon 程序集在构建时返回定义。
  • 在运行时，装配接口用于返回构建的组件。这避免了使用“魔术字符串”
  • 同样，对其他组件的引用也不需要“魔术字符串”——而是使用方法名称。
  • TyphoonDefinitions 可以声明它们具有静态和运行时依赖项的混合，后者在程序集接口上声明。这提供了一种快速而强大的方式来实现工厂模式，并避免编写样板代码。

主要理由是允许 IDE 重构和代码完成，而无需构建额外的工具支持。

其他一些区别：

  • “按类型注入”（自动装配）仅可用于属性（ObjC 运行时不会为初始化程序或方法参数保留此信息）。

  • Typhoon 提供了一个专门为移动和桌面软件设计的默认范围。

  • 您可能已经看到了一些示例，其中定义注入了程序集本身。这类似于 Spring 的 BeanFactoryAware，无需将您的代码显式耦合到 Typhoon（非侵入性）。它允许从一个对象图（例如视图控制器）到另一个对象图 - 这是移动和桌面应用程序中的常见要求。

最后，Spring 及其产品组合的基础一方面是“依赖注入”和“AOP”（用于事务管理、安全等）。此时 Typhoon 只做依赖注入，虽然我们觉得正式的 AOP 框架，用切入点表达语言会很有用。

Typhoon 的早期版本允许使用 Spring 样式的 XML，但是这在 Objectives-C 开发人员中并不是一个流行的特性。

于 2014-10-20T14:25:04.477 回答