为什么伞架不鼓励?

我想分发框架A.框架A依赖于框架B.我想我的框架的用户只需要包括框架A,但仍然有程序访问框架B.

苹果一直使用“Umbrella Frameworks”这个概念来做这个事情,但是这个文档有这个话题:

不要创build伞框架

尽pipe可以使用Xcode创build伞架,但对于大多数开发人员来说,这样做是不必要的,不build议使用。 苹果公司使用伞架来掩盖操作系统中的库之间的一些相互依赖关系。 几乎在所有情况下,您都应该能够将代码包含在一个标准的框架包中。 另外,如果你的代码是足够模块化的,你可以创build多个框架,但是在这种情况下,模块之间的依赖关系是最小的或不存在的,不应该为它们创build一个保护伞。

为什么这种方法不受欢迎? 是什么使它成为苹果相互依赖的框架问题的一个很好的解决scheme,但不是我的?

如果你是所有涉及的框架的唯一分销商,那么伞形框架只有意义,你将把所有的框架打包在一起,作为一个单独的版本化的软件包,它们将一起升级。 如果那是你的情况,那很好,但这是非常不寻常的情况。 在cocoa开发的世界里,除了苹果之外,任何人都会遇到这种情况。

首先,如果您是给定框架的唯一分销商,伞式框架才有意义。 例如,假设你想包含libcurl作为伞架的一部分。 现在另外一些打包者也希望把libcurl作为他的伞架的一部分。 现在我们有一个链接时间冲突,可能会导致链接错误或更糟,未定义的运行时行为。 我自己追赶了这些 他们非常不愉快。 避免这种情况的唯一方法是每个框架/库只有一个版本。 伞形框架鼓励相反。

即使你只是将自己的代码分解成子代,这意味着其他供应商可能会在你自己的伞架中使用你的子框架,导致同样的问题。 记住,如果你说你可以作为第三方来使用伞架,那么其他厂商也可以。

第二点,伞架只有在你控制所有子架构的版本控制时才有意义。 试图修补一个相互依赖的框架,在我的经验中几乎总是一场灾难。

操作系统供应商由于其系统的大小和普遍性而具有不寻常的情况。 在一个规模上有意义的事情往往在另一个规律上是没有意义的。 NSResponder是完全正确的。 当你提供一个完整的,数千个包的环境时,权衡是不一样的,这个环境是为这个平台编写的每个程序的基础。 但即使是苹果公司也只有less数几个大型的伞式框架,而且它们总是围绕着它们提供和控制版本的库。 这主要是为了简化开发者的工作,否则他们不得不追逐数十个图书馆和框架来编译。 没有第三方有这种情况,所以第三方很less需要这种解决scheme。 要求你的客户链接两个库是完全不同的,然后要求他们链接20.如果你提供了20个框架,所有的一起工作,你控制,那么也许你应该使用一把伞,但也可能有太多的框架第三方。

我在这里的大部分讨论都是以OS X来说的。在iOS上,这对于第三方来说是一个非问题。 静态库不能链接其他静态库,因为肯定会发生冲突。

从理论上讲,我在这里讨论的大部分问题都是链接器的基本技术限制。 链接器没有一个很好的方式来pipe理多个版本的库,所以碰撞是一个严重的问题。 .NET程序集试图提供更多的灵活性。 我对.NET开发不够熟悉,不知道这是否成功。 我对大型多组件系统的经验是,更简单,不太灵活的解决scheme对于大多数问题是最好的。 (但是,草地总是比较绿的….)

一个问题是,框架B的版本现在被绑定到框架A的版本。这可能是你在某些情况下而不是其他的情况。 如果框架B可能被一个也想使用框架A的应用程序独立使用,则应用程序可能会发现自己处于A包含的B版本不是其需要或需要的版本的情况。

框架B是一个应用程序可以独立于A使用的框架吗? 如果是这样,那么你可能会遇到这种情况。 如果B是A以外的框架,那么你不应该遇到这种情况。

在苹果公司的情况下,他们提供了大量的代码,而这些子框架经常被单独修改。 如果您提供了几个框架的演出,那么您可能想要继续并制定一个伞形框架。 如果没有,你可能不需要麻烦。