为什么不建议使用伞形框架？

Question

我想分发框架A。框架A依赖于框架B。我希望框架的用户只需要包括框架A，但仍然可以通过编程方式访问框架B。Apple始终使用“伞框架”（Umbrella Frameworks）的概念来执行此操作，但是文档中包含以下主题：不要创建伞框架尽管可以使用Xcode创建伞形框架，但是对于大多数开发人员而言，这样做是不必要的，因此不建议这样做。苹果使用伞形框架掩盖了操作系统中库之间的某些相互依赖关系。在几乎所有情况下，您都应该可以将代码包含在单个标准框架包中。另外，如果您的代码具有足够的模块化，则可以创建多个框架，但是在那种情况下，模块之间的依赖关系将是最小的或不存在，因此不应保证为它们创建保护伞。为什么不鼓励这种方法？是什么让它成为解决Apple相互依赖框架问题而不是我的框架的好解决方案？

Answer 1

仅当您是所有涉及的框架的唯一分发者时，伞框架才有意义，并且您将所有框架打包为一个单独的版本包，将一起升级。如果那是您的情况，那很好，但这是一种非常不寻常的情况。在可可开发世界中，除了苹果公司以外的任何人都处于这种情况是极为不寻常的。

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

即使您只是将自己的代码分解成多个子部分，这也意味着其他供应商可能会在自己的伞形框架中使用子框架，从而导致同样的问题。请记住，如果您说作为第三方使用伞式框架是可以的，那么其他供应商也可以。

第二点，仅当您控制所有子框架的版本控制时，伞式框架才有意义。在我的经验中，尝试修补一组相互依赖的框架几乎总是一个灾难。

操作系统供应商由于其系统的规模和普遍性而出现了异常情况。在一个范围内有意义的事情通常在另一个范围内没有意义。NSResponder对此完全正确。当您提供一个完整的，成千上万的软件包环境时，这些取舍是不同的，这是为平台编写的每个程序的基础。但是，即使苹果公司也只有少数大型伞式框架，它们始终是它们提供和控制其版本的库的包装。这主要是为了简化开发人员的工作，否则他们将不得不追逐数十个库和框架来进行编译。没有第三方有这种情况，因此很少有第三方需要此解决方案。

我在这里的大部分讨论是针对OS X的。在iOS上，这不是第三方的问题。由于肯定会发生冲突，因此静态库绝不能链接其他静态库。

从理论上讲，我在这里讨论的大多数问题从根本上限制了链接程序的技术限制。链接器没有管理多种版本库的好方法，因此冲突是一个严重的问题。.NET程序集试图为此提供更多的灵活性。我对.NET开发还不太熟悉，无法说出它是否成功。我在大型多组件系统上的经验是，对于大多数问题而言，更简单，更不灵活的解决方案是最好的。（但是，那草总是更绿了...。）

Answer 2

以苹果公司为例，他们提供了大量的代码，而这些子框架通常需要单独修订。如果要交付几份框架，则可能要继续制作一个伞形框架。如果没有，您可能不需要麻烦。