【问题标题】：Framework vs. Toolkit vs. Library [duplicate]框架与工具包与库 [重复]
【发布时间】：2011-03-04 16:56:30
【问题描述】：

框架、工具包和库之间有什么区别？

【问题讨论】：

无价之宝。 @martijn-pieters 将此问题标记为重复，并将重复关闭为“太宽泛”。我无缘无故没有进入这个页面，这些问题很有价值。原则上要对他们俩都投赞成票。
我也是在这里制作的。是的，这只是语义，但是当我们拥有良好、一致的词汇时，对话会更容易。

标签： terminology

【解决方案1】：

非常非常相似，框架通常比库更完善和更完整，工具包可以简单地是类似库和框架的集合。

一个非常好的问题，在本质上甚至可能有点主观，但我相信这是我能给出的最佳答案。

【讨论】：

【解决方案2】：

库只是封装在一个包中的方法/函数的集合，可以导入到代码项目中并重复使用。

框架是一个强大的库或库集合，可为您的代码提供“基础”。框架遵循控制反转模式。例如，.NET 框架是一个庞大的内聚库集合，您可以在其中构建应用程序。您可以争辩说框架和库之间没有太大区别，但是当人们说“框架”时，它通常意味着更大、更健壮的库套件，它们将成为应用程序不可或缺的一部分。

我对工具包的看法与对 SDK 的看法相同。它带有文档、示例、库、包装器等。同样，您可以说这与框架相同，您可能会这样做是对的。

它们几乎都可以互换使用。

【讨论】：

【解决方案3】：

库和框架之间最重要的区别，实际上定义的区别是Inversion of Control。

这是什么意思？嗯，这意味着当您调用库时，您处于控制之中。但是有了框架，控制就被颠倒了：框架调用你。（这被称为好莱坞原则：不要打电话给我们，我们会打电话给你。）这几乎是框架的定义。如果它没有控制反转，它就不是一个框架。（我在看着你，.NET！）

基本上，所有的控制流都已经在框架中了，只有一堆预定义的白点，你可以用你的代码来填写。

另一方面，库是您可以调用的功能集合。

我不知道“工具包”这个术语是否定义得很好。只是“工具包”这个词似乎暗示了某种模块化，即一组您可以从中挑选的独立库。那么，是什么让一个工具包与一堆独立的库不同呢？集成：如果您只有一堆独立的库，则无法保证它们可以很好地协同工作，而工具包中的库被设计为可以很好地协同工作——您不必使用 all 他们。

但这只是我对这个词的解释。与定义明确的库和框架不同，工具包没有被广泛接受的定义。

【讨论】：

这可能是不正确的。框架可以但不必执行控制反转。你对 CSS 框架有什么看法？一个框架在你不问的情况下默默地为你做很多事情。这就是它们不能与另一个同类框架组合的原因（如果你组合了 2 个 CSS 框架，请准备好迎接惊喜）。他们可以在没有您询问的情况下做的一件事就是拥有应用程序的控制流。我认为@Sridhar-Sarnobat 的答案可能更好
作为可靠参考，Design Patterns 一书的第 1.6 节，GoF 将 toolkit 定义为 class 库, 即 subroutine 库的面向对象等价物：'通常，应用程序会合并来自一个或多个称为 toolkits 的预定义类库中的类。 工具包是一组相关且可重用的类，旨在提供有用的通用功能。工具包的一个示例是一组用于列表、关联表、堆栈等的集合类。 C++ I/O 流库是另一个例子。
... 工具包不会将特定设计强加于您的应用程序；它们只是提供可以帮助您的应用程序完成其工作的功能。它们让您作为实施者避免重新编写常用功能。工具包强调代码重用。它们是面向对象的子程序库等价物。'

【解决方案4】：

Martin Fowler 在Inversion of Control 上的文章中讨论了库和框架之间的区别：

控制反转是是什么使框架与图书馆。 库本质上是一个您可以调用的一组函数，这些天通常组织成类。每个电话都会做一些工作，并且将控制权返回给客户端。

一个框架体现了一些抽象设计，内置更多行为。为了使用它，您需要 插入你的行为在不同的地方框架通过子类化或通过插入您自己的类。 该框架的代码然后调用你的代码在这些点上。

总结一下：您的代码调用库，但框架调用您的代码。

【讨论】：

【解决方案5】：

关于 Mittag 的正确答案：

一个简单的例子。假设您在其中一个类中实现了ISerializable 接口（.Net）。然后，您使用 .Net 的框架质量，而不是它的库质量。您填写“白点”（如 mittag 所说），您就完成了骨架。您必须提前知道框架将如何对您的代码“做出反应”。实际上 .net 是一个框架，这就是我不同意 Mittag 观点的地方。

完整、完整的答案在this book 的第 19 章（整章专门讨论这个主题）中非常清晰地给出，这是一本非常好的书顺便说一下（根本不是“仅用于 Smalltalk”）。

【讨论】：

嗯，这是一个有趣的观点。我认为 .Net Framework 实际上是一个工具包，由库、框架和虚拟机组成。大多数框架也包含库，并且通常还包含其他工具，因此从这个意义上说，它们成为围绕框架本身的工具包，全部捆绑在一起。所以我想你可以说 .Net 作为一个框架是公平的。
.Net 的“框架”品质真的超过了它作为库和工具集的品质吗？我对此表示怀疑，所以我觉得这就是争论如此激烈的原因。它不是比库和虚拟机更多的框架，所以我觉得它会更好地定义一个工具包。甚至我猜是一个平台。因为工具包现在经常偏向于 UI 的东西。

【解决方案6】：

简介

有各种与相关代码集合相关的术语，它们既有历史意义（本答案的目的是 1994/5 之前）也有当前含义，读者应该注意这两者，尤其是在阅读关于历史时代的计算/编程。

图书馆

无论从历史上还是现在，库都是与特定任务相关的代码集合，或者是在大致相同的抽象级别上运行的密切相关任务的集合。它本身通常没有任何目的或意图，旨在供（消费）客户端代码使用并与客户端代码集成以协助客户端代码执行其任务。

工具包

从历史上看，工具包是一个更有针对性的库，具有明确的特定用途。目前，该术语已经失宠，并且几乎仅（据作者所知）用于当前时代的图形小部件和 GUI 组件。工具包通常会在比库更高的抽象层上运行，并且通常会使用和使用库本身。与库不同，工具包代码通常用于执行客户端代码的任务，例如构建窗口、调整窗口大小等。工具包中的较低抽象级别要么是固定的，要么可以由客户端自行操作以被禁止的方式编码。（想想 Window 样式，可以是固定的，也可以由客户端代码提前更改。）

框架

从历史上看，框架是一套相互关联的库和模块，它们分为“通用”或“特定”类别。通用框架旨在通过提供通用功能（例如跨平台内存管理、多线程抽象、动态结构（以及一般的通用结构））来提供用于构建应用程序的综合集成平台。历史通用框架（没有依赖注入，见下文）几乎普遍被 OO 语言中的多态模板化（参数化）打包语言产品所取代，例如 C++ 的 STL，或非 OO 语言的打包库（保证 Solaris C 头文件））。通用框架在不同的抽象层上运行，但普遍是低级别的，就像库一样，依赖于客户端代码在它们的帮助下执行其特定任务。

“特定”框架在历史上是为单一（但通常是庞大的）任务开发的，例如工业系统的“命令和控制”系统，以及早期的网络堆栈，并在高抽象级别上运行，类似的工具包被用于执行客户端代码任务。

目前，框架的定义变得更加集中，并以其他地方提到的“控制反转”原则作为指导原则，因此程序流程以及执行都由框架执行。然而，框架仍然针对特定的输出；例如，用于特定操作系统的应用程序（例如用于 MS Windows 的 MFC），或者用于更通用的工作（例如 Spring 框架）。

SDK：“软件开发工具包”

SDK 是一组工具，可帮助程序员创建和部署代码/内容，这些代码/内容非常专门针对在非常特定的平台上或以非常特定的方式运行。 SDK 可以简单地由一组库组成，这些库必须仅由客户端代码以特定方式使用，并且可以正常编译，直到一组二进制工具，这些工具创建或调整二进制资产以生成其（SDK 的) 输出。

引擎

引擎（在代码收集术语中）是一个二进制文件，它将以某种方式运行定制内容或处理输入数据。游戏和图形引擎可能是该术语最流行的用户，并且几乎普遍与 SDK 一起使用以针对引擎本身，例如 UDK（虚幻开发工具包），但也存在其他引擎，例如搜索引擎和 RDBMS 引擎.

引擎通常（但并非总是）只允许其客户访问其内部的一部分。大多数情况下，要么针对不同的体系结构，要么更改引擎输出的呈现方式，要么出于调整目的。开源引擎的定义是开放给客户根据需要进行更改和更改，并且一些专有引擎是完全固定的。然而，世界上最常用的引擎几乎可以肯定是 JavaScript 引擎。嵌入到任何地方的每个浏览器中，都有大量的 JavaScript 引擎，它们会将 JavaScript 作为输入，处理它，然后输出到渲染。

API：“应用程序编程接口”

我要回答的最后一个术语是我个人的问题：API，在历史上用于描述应用程序或环境的外部接口，它本身能够独立运行，或者至少可以在没有任何程序的情况下执行其任务初始执行后必要的客户干预。诸如数据库、文字处理器和 Windows 系统之类的应用程序将向外部接口公开一组固定的内部挂钩或对象，然后客户端可以调用/修改/使用等以执行原始应用程序可以执行的功能。 API 在通过 API 提供多少功能以及客户端代码（重）使用多少核心应用程序之间有所不同。（例如，文字处理 API 可能需要在客户端代码的每个实例运行时，或者可能只是其链接库之一时，在后台加载整个应用程序；而正在运行的窗口系统将创建由自身管理的内部对象和将句柄传回客户端代码以供使用。

目前，术语 API 的范围更广，通常用于描述此答案中的几乎所有其他术语。实际上，适用于该术语的最常见定义是 API 为另一软件（API 的客户端代码）提供了一个约定的外部接口。在实践中，这意味着 API 依赖于语言，并且具有由上述代码集合之一提供的具体实现，例如库、工具包或框架。要查看特定领域，例如协议，API 与协议不同，协议是表示一组规则的更通用术语，但是特定协议/协议套件的单独实现将外部接口暴露给其他软件最常被称为 API。

备注

如上所述，上述术语的历史和当前定义已经发生变化，这可以看作是对基础计算原理和范式的科学理解的进步，以及特定软件模式的出现.特别是 90 年代初的 GUI 和 Windowing 系统帮助定义了许多这些术语，但是由于 OS Kernel 和 Windowing 系统在大众消费者操作系统（也许是 Linux）中的有效混合，以及依赖注入的大规模采用/控制反转作为一种使用库和框架的机制，这些术语不得不改变它们各自的含义。

附言（一年后）

在仔细考虑了这个主题一年多之后，我拒绝将 IoC 原则作为框架和库之间的决定性区别。有大量受欢迎的作家说它是，但几乎相同数量的人说它不是。那里有太多的“框架”，它们不使用 IoC 来说它是定义原则。对嵌入式或微控制器框架的搜索揭示了一大堆不使用 IoC 的情况，我现在相信 .NET 语言和 CLR 是“通用”框架的可接受的后代。说 IoC 是决定性的特征，恐怕我太死板了，我无法接受，并且拒绝任何将自己作为与上述历史表现相匹配的框架的东西。

有关非 IoC 框架的详细信息，请参阅上面提到的许多嵌入式和微型框架，以及任何不通过该语言提供回调的语言的历史框架（好的。回调可以被黑客攻击任何设备使用现代注册系统，但不是普通程序员），显然是 .NET 框架。

【讨论】：

看你的更新，有没有细化的区别？或者你是在暗示“框架”只是一个模糊的依赖，它为你做了一些事情？我想作为一名应用程序开发人员，不必担心嵌入式程序员的词汇量。
您能否在 API 的解释中具体说明/详细说明“外部接口”是什么意思？
我认为揭穿 IoC 论点的更好方法是问“库或工具包是否也可以控制消费者？”我认为答案是肯定的。

【解决方案7】：

我认为这有点主观。该工具包是最简单的。它只是一堆可以使用的方法、类。
库与框架问题我通过使用它们的方式有所不同。很久以前，我在某个地方读到了完美的答案。框架调用你的代码，但另一方面你的代码调用库。

【讨论】：

【解决方案8】：

框架：安装在您的机器上并允许您与之交互。如果没有框架，您将无法将编程命令发送到您的机器

库：旨在解决某个问题（或与同一类别相关的多个问题）

工具包：多段代码的集合，可以解决多个问题上的多个问题（就像一个工具箱）

【讨论】：

【解决方案9】：

图书馆

我认为一个库是已经编码的代码，你可以使用它，这样就不必再次编码，这是一致的。代码的组织方式必须允许您查找所需的功能并从您自己的代码中使用它。

大多数编程语言都带有标准库，尤其是一些实现某种集合的代码。这始终是为了方便您不必自己编写这些代码。同样，大多数编程语言都具有允许您从库中查找功能的结构，例如动态链接、命名空间等。

因此，发现自己经常需要重复使用的代码是放入库中的好代码。

工具包

用于特定目的的一组工具。这是一致的。问题是，什么被认为是工具，什么不是。我想说没有固定的定义，它取决于自称为工具包的事物的上下文。工具的示例可以是库、小部件、脚本、程序、编辑器、文档、服务器、调试器等。

要注意的另一件事是“特定目的”。这始终是正确的，但目的的范围很容易根据制作工具包的人而改变。所以它可以很容易地成为程序员的工具包，也可以是字符串解析工具包。一个是如此广泛，它可以拥有涉及所有与编程相关的工具，而另一个则更精确。

SDK 通常是工具包，因为它们尝试将一组工具（通常是多种工具）捆绑到一个包中。

我认为共同点是一个工具为你做某事，要么完全，要么帮助你做这件事。工具包只是一组工具，它们都执行或帮助您执行一组特定的活动。

框架

框架的定义并不完全一致。对于任何可以构建您的代码的东西，它似乎都是一个笼统的术语。这意味着：任何构成或支持您的代码的结构。

这意味着您针对框架构建代码，而针对代码构建库。

但是，有时框架一词的使用似乎与工具包甚至库的含义相同。 .Net 框架主要是一个工具包，因为它由作为库的 FCL 和作为虚拟机的 CLR 组成。所以你会认为它是在 Windows 上进行 C# 开发的工具包。 Mono 是用于在 Linux 上进行 C# 开发的工具包。然而，他们称其为框架。以这种方式思考也是有道理的，因为它可以为您的代码构建框架，但是框架应该更多地支持并将事物结合在一起，然后做任何工作，所以我认为这不是您应该使用的方式词。

我认为业界正试图让框架意味着一个已经编写好的程序，其中缺少您必须提供或定制的部分。我认为这是一件好事，因为工具包和库对于“框架”的其他用法来说是非常精确的术语。

【讨论】：

【解决方案10】：

图表

如果你是一个更直观的学习者，这里有一个图表可以让你更清楚：

（学分：http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks）

【讨论】：

一个框架的假定好处之一是它可以移植到不同的平台，问题更少。但在实践中，将应用程序从一个平台移植到另一个平台似乎不太可能发生，我不想招致它带来的麻烦。
对于鸟瞰方法，您已经掌握了。

【解决方案11】：

answer provided by Barrass 可能是最完整的。然而，解释可以很容易地表述得更清楚。大多数人都忽略了这些都是嵌套概念的事实。所以让我为你列出来。

写代码时：

最终您会发现您在程序中重复的代码部分，因此您将它们重构为函数/方法。
最终，在编写了几个程序之后，您会发现自己正在将已经制作的功能复制到新程序中。为了节省自己的时间，您将这些函数捆绑到 Libraries 中。
最终，您发现自己每次使用某些库时都会创建相同类型的用户界面。因此，您重构您的工作并创建一个工具包，让您可以更轻松地从通用方法调用创建您的 UI。
最终，您编写了如此多的应用程序，它们使用相同的工具包和库，以至于您创建了一个 Framework，其中已经提供了该样板代码的通用版本，因此您需要做的就是设计UI 的外观并处理用户交互产生的事件。

一般来说，这完全解释了术语之间的差异。

【讨论】：

这个答案是对包括 IoC 的前两个答案的补充，但是，因为它省略了 IoC 并将框架与“样板代码”混为一谈，所以这个答案是不够的，也不是完全正确的。
鉴于控制反转 (IoC) 既不是框架的要求，也不是框架独有的，而且框架的主要工作是提供样板性质的代码（即通常在多个应用程序中重用，但在每种情况下都需要进行微小的更改，并且可以重新分解以将更改视为参数或配置），我会说我的概括性答案非常彻底和正确。

【解决方案12】：

其他人注意到 .net 可能既是框架又是库和工具包，具体取决于您使用的部分，但也许一个示例会有所帮助。用于处理数据库的实体框架是 .net 的一部分，它确实使用了控制反转模式。你让它知道你的模型，它会弄清楚如何处理它们。作为程序员，它要求您了解“框架的思想”，或者更实际地了解设计者的思想以及他们将如何处理您的输入。另一方面，datareader 和相关调用只是一个工具，用于在表/视图中获取或放入数据并使其可供您使用。它永远不会理解如何获取父子关系并将其从对象转换为关系，您将使用多种工具来做到这一点。但是您可以更好地控制数据的存储方式、时间、交易等。

【讨论】：