为什么伞架不鼓励？

Question

我想分发框架A.框架A取决于框架B.我想我的框架的用户只需要包含框架A，但仍然有框架B的编程访问。

苹果一直这样做采用“伞框架”的概念，但这个主题中的文档：

不要创建伞框架

虽然可以使用Xcode的雨伞框架来创建，做 所以对大多数德是不必要的velopers，不建议。 Apple 使用伞形框架来掩盖操作系统中的 库之间的一些相互依赖关系。在几乎所有情况下，您应该是 能够将您的代码包含在单个标准框架包中。 或者，如果您的代码是足够模块化的，则可以创建多个框架，但在这种情况下，模块之间的依赖关系最小或不存在，因此不应保证为其创建一个保护伞。

为什么这种方法不鼓励？是什么使它成为苹果相互依赖的框架问题的一个很好的解决方案，但不适合我的？

Answer 1

如果您是所有涉及的框架的唯一分销商，则伞形框架才有意义，并且您将将所有框架打包在一起，作为将一起升级的单个版本化的包。如果那是你的情况，那很好，但这是非常不寻常的情况。在可可开发的世界里，除了苹果之外，任何人都会遇到这种情况。

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

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

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

由于OS系统的大小和无处不在，OS供应商有一种不寻常的情况。在一个规模上有意义的事情往往对另一个规律没有意义。 NSResponder对此完全正确。当您提供完整的数千个软件包环境时，权衡是不同的，这些环境是为该平台编写的每个程序的基础。但即使是苹果公司也只有少量的大型框架，而且它们总是围绕它们提供的库和包装版本进行包装。这主要是为了简化开发人员的工作，否则他们不得不追逐数十个图书馆和框架来编译某些东西。没有第三方有这种情况，所以第三方很少需要这种解决方案。要求你的客户连接两个库是完全不同的，然后让他们链接20.如果你提供了20个框架，它们一起工作并且你控制了，那么你可能应该使用一把伞，但是也许你有太多的框架第三方。

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

理论上，我在这里讨论的大部分问题都是链接器的基本技术限制。链接器没有很好的方法来管理多个版本的库，因此碰撞是一个严重的问题。 .NET程序集试图提供更多的灵活性。我对.NET开发不够熟悉，无法说明这是否成功。我对大型多组件系统的经验是，更简单，不太灵活的解决方案对于大多数问题是最好的。 （但是，草地总是更绿色....）

Answer 2

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

Answer 3

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

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