为什么伞架不鼓励？
我想分发框架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以外的框架，那么你不应该遇到这种情况。
在苹果公司的情况下，他们提供了大量的代码，而这些子框架经常被单独修改。 如果您提供了几个框架的演出，那么您可能想要继续并制定一个伞形框架。 如果没有，你可能不需要麻烦。
