框架与工具包与库[重复]

最新推荐文章于 2022-12-14 21:37:17 发布

xfxf996

最新推荐文章于 2022-12-14 21:37:17 发布

阅读量391

点赞数

文章标签： terminology

原文链接：https://oldbug.net/q/CpOw/Framework-vs-Toolkit-vs-Library-duplicate

版权

本文翻译自：Framework vs. Toolkit vs. Library [duplicate]

This question already has an answer here: 这个问题在这里已有答案：

What is the difference between a framework and a library? 框架和库有什么区别？ [closed] 19 answers [已关闭] 19个答案

What is the difference between a Framework, a Toolkit and a Library? 框架，工具包和库之间有什么区别？

#1楼

参考：https://stackoom.com/question/CpOw/框架与工具包与库-重复

#2楼

Introduction 介绍

There are various terms relating to collections of related code, which have both historical (pre-1994/5 for the purposes of this answer) and current implications, and the reader should be aware of both, particularly when reading classic texts on computing/programming from the historic era. 关于相关代码的集合有各种各样的术语，它们既有历史的（1994/5年前为本答案的目的）和当前的含义，读者应该意识到这两者，特别是在阅读关于计算/编程的经典文本时从历史时代开始。

Library 图书馆

Both historically, and currently, a library is a collection of code relating to a specific task, or set of closely related tasks which operate at roughly the same level of abstraction. 历史上和目前，库都是与特定任务相关的代码集合，或者是在大致相同的抽象级别上操作的一组密切相关的任务。 It generally lacks any purpose or intent of it's own, and is intended to be used by (consumed) and integrated with client code to assist client code in executing it's tasks. 它通常缺乏自己的任何目的或意图，并且旨在被（使用）使用并与客户端代码集成以帮助客户端代码执行它的任务。

Toolkit 工具包

Historically, a toolkit is a more focussed library, with a defined and specific purpose. 从历史上看，工具包是一个更集中的库，具有明确的特定目的。 Currently, this term has fallen out of favour, and is used almost exclusively (to this author's knowledge) for graphical widgets, and GUI components in the current era. 目前，该术语已经失宠，并且几乎完全（对于本作者的知识）用于当前时代的图形小部件和GUI组件。 A toolkit will most often operate at a higher layer of abstraction than a library, and will often consume and use libraries itself. 工具包通常在比库更高的抽象层上运行，并且通常会自己使用和使用库。 Unlike libraries, toolkit code will often be used to execute the task of the client code, such as building a window, resizing a window, etc. The lower levels of abstraction within a toolkit are either fixed, or can themselves be operated on by client code in a proscribed manner. 与库不同，工具包代码通常用于执行客户端代码的任务，例如构建窗口，调整窗口大小等。工具箱中较低级别的抽象要么是固定的，要么本身可以由客户端操作以被禁止的方式编码。 (Think Window style, which can either be fixed, or which could be altered in advance by client code.) （思考窗口样式，可以修复，也可以通过客户端代码预先更改。）

Framework 骨架

Historically, a framework was a suite of inter-related libraries and modules which were seperated into either 'General' or 'Specific' categories. 从历史上看，框架是一组相互关联的库和模块，它们分为“常规”或“特定”类别。 General frameworks were intended to offer a comprehensive and integrated platform for building applications by offering general functionality, such as cross platform memory management, multi-threading abstractions, dynamic structures (and generic structures in general). 通用框架旨在通过提供通用功能（例如跨平台内存管理，多线程抽象，动态结构（以及通用通用结构））来提供用于构建应用程序的全面且集成的平台。 Historical general frameworks (Without dependency injection, see below) have almost universally been superseded by polymorphic templated (parameterised) packaged language offerings in OO languages, such as the STL for C++, or in packaged libraries for non-OO languages (guaranteed Solaris C headers). 历史通用框架（没有依赖注入，见下文）几乎普遍被OO语言中的多态模板（参数化）打包语言产品所取代，例如STL for C ++，或者用于非OO语言的打包库（保证的Solaris C头文件）。）。 General frameworks operated at differing layers of abstraction, but universally low level, and like libraries relied on the client code carrying out it's specific tasks with their assistance. 一般框架在不同的抽象层运行，但普遍低级，并且像库一样依赖客户端代码在他们的帮助下执行它的特定任务。

'Specific' frameworks were historically developed for single (but often sprawling) tasks, such as "Command and Control" systems for industrial systems, and early networking stacks, and operated at a high level of abstraction and like toolkits were used to carry out execution of the client codes tasks. “特定”框架历史上是针对单个（但通常是庞大的）任务开发的，例如用于工业系统的“命令和控制”系统，以及早期的网络堆栈，并且在高级抽象操作下运行，并且类似工具包用于执行客户端代码任务。

Currently, the definition of a framework has become more focussed and taken on the "Inversion of Control" principle as mentioned elsewhere as a guiding principle, so program flow, as well as execution is carried out by the framework. 目前，框架的定义已经变得更加集中，并且在其他地方提到的“控制反转”原则作为指导原则，因此程序流程以及执行由框架执行。 Frameworks are still however targetted either towards a specific output; 然而，框架仍然针对特定输出; an application for a specific OS for example (MFC for MS Windows for example), or for more general purpose work (Spring framework for example). 例如，特定操作系统的应用程序（例如，用于MS Windows的MFC），或用于更通用的工作（例如Spring框架）。

SDK: "Software Development Kit" SDK：“软件开发套件”

An SDK is a collection of tools to assist the programmer to create and deploy code/content which is very specifically targetted to either run on a very particular platform or in a very particular manner. SDK是一组工具，用于帮助程序员创建和部署代码/内容，这些代码/内容非常专门针对在非常特定的平台上运行或以非常特定的方式运行。 An SDK can consist of simply a set of libraries which must be used in a specific way only by the client code and which can be compiled as normal, up to a set of binary tools which create or adapt binary assets to produce it's (the SDK's) output. SDK可以只包含一组库，这些库必须仅以客户端代码的特定方式使用，并且可以正常编译，最多可以创建或调整二进制资产以生成它的二进制工具集（SDK的）输出。

Engine 发动机

An Engine (In code collection terms) is a binary which will run bespoke content or process input data in some way. 引擎（在代码集合术语中）是一个二进制文件，它将以某种方式运行定制内容或处理输入数据。 Game and Graphics engines are perhaps the most prevelant users of this term, and are almost universally used with an SDK to target the engine itself, such as the UDK (Unreal Development Kit) but other engines also exist, such as Search engines and RDBMS engines. 游戏和图形引擎可能是这个术语中最普遍的用户，几乎普遍使用SDK来定位引擎本身，例如UDK（虚幻开发工具包），但也存在其他引擎，例如搜索引擎和RDBMS引擎。

An engine will often, but not always, allow only a few of it's internals to be accessible to it's clients. 引擎通常（但并非总是）只允许其客户端访问其中的一些内部。 Most often to either target a different architecture, change the presentation of the output of the engine, or for tuning purposes. 通常要么针对不同的架构，要么改变引擎输出的表示，要么用于调整目的。 Open Source Engines are by definition open to clients to change and alter as required, and some propriety engines are fixed completely. 根据定义，开源引擎可以根据需要对客户进行更改和更改，并且某些适当的引擎可以完全修复。 The most often used engines in the world however, are almost certainly Javascript Engines. 然而，世界上最常用的引擎几乎肯定是Javascript引擎。 Embedded into every browser everywhere, there are a whole host of JavaScript engines which will take javascript as an input, process it, and then output to render. 嵌入到每个浏览器的所有地方，都有一大堆JavaScript引擎，它们将javascript作为输入，处理它，然后输出到渲染。

API: "Application Programming Interface" API：“应用程序编程接口”

The final term I am answering is a personal bugbear of mine: API, was historically used to describe the external interface of an application or environment which, itself was capable of running independently, or at least of carrying out it's tasks without any necessary client intervention after initial execution. 我回答的最后一个术语是我的个人问题：API，历史上用于描述应用程序或环境的外部接口，它本身能够独立运行，或者至少执行它的任务而无需任何必要的客户端干预初步执行后。 Applications such as Databases, Word Processors and Windows systems would expose a fixed set of internal hooks or objects to the external interface which a client could then call/modify/use, etc to carry out capabilities which the original application could carry out. 诸如数据库，字处理器和Windows系统之类的应用程序将向外部接口公开一组固定的内部挂钩或对象，然后客户端可以调用/修改/使用它们以执行原始应用程序可以执行的功能。 API's varied between how much functionality was available through the API, and also, how much of the core application was (re)used by the client code. API在通过API提供的功能数量以及客户端代码（重新）使用了多少核心应用程序之间存在差异。 (For example, a word processing API may require the full application to be background loaded when each instance of the client code runs, or perhaps just one of it's linked libraries; whereas a running windowing system would create internal objects to be managed by itself and pass back handles to the client code to be utilised instead. （例如，文字处理API可能要求在客户端代码的每个实例运行时将完整应用程序加载到后台，或者可能只需要其中一个链接库;而正在运行的窗口系统将创建内部对象以由其自身管理。将句柄传递回要使用的客户端代码。

Currently, the term API has a much broader range, and is often used to describe almost every other term within this answer. 目前，术语API具有更广泛的范围，并且通常用于描述该答案中的几乎所有其他术语。 Indeed, the most common definition applied to this term is that an API offers up a contracted external interface to another piece of software (Client code to the API). 实际上，应用于该术语的最常见定义是API为另一个软件提供了一个签约的外部接口（API的客户端代码）。 In practice this means that an API is language dependent, and has a concrete implementation which is provided by one of the above code collections, such as a library, toolkit, or framework. 实际上，这意味着API依赖于语言，并且具有由上述代码集之一（例如库，工具箱或框架）提供的具体实现。 To look at a specific area, protocols, for example, an API is different to a protocol which is a more generic term representing a set of rules, however an individual implementation of a specific protocol/protocol suite that exposes an external interface to other software would most often be called an API. 为了查看特定区域，协议，例如，API与协议不同，协议是表示一组规则的更通用的术语，但是特定协议/协议套件的单独实现，其将外部接口暴露给其他软件通常被称为API。

Remark 备注

As noted above, historic and current definitions of the above terms have shifted, and this can be seen to be down to advances in scientific understanding of the underlying computing principles and paradigms, and also down to the emergence of particular patterns of software. 如上所述，上述术语的历史和当前定义已经发生了变化，这可以看作是对基础计算原理和范例的科学理解的进步，也归结为特定软件模式的出现。 In particular, the GUI and Windowing systems of the early nineties helped to define many of these terms, but since the effective hybridisation of OS Kernel and Windowing system for mass cunsumer operating systems (bar perhaps Linux), and the mass adoption of dependency injection/inversion of control as a mechanism to consume libraries and frameworks, these terms have had to change their respective meanings. 特别是，九十年代早期的GUI和Windowing系统帮助定义了许多这些术语，但是自从OS Kernel和Windowing系统有效混合用于大规模操作系统（也许是Linux），以及依赖注入的大量采用/将控制反转作为消费图书馆和框架的机制，这些术语必须改变各自的含义。

PS (A year later) PS（一年后）

After thinking carefully about this subject for over a year I reject the IoC priciple as the defining difference between a framework and a library. 在仔细考虑了这个主题超过一年之后，我拒绝将IoC原则作为框架和库之间的定义区别。 There ARE a large number of popular authors who say that it is, but there are an almost equal number of people who say that it isn't. 有许多受欢迎的作者说它是，但有几乎相同数量的人说它不是。 There are simply too many 'Frameworks' out there which DO NOT use IoC to say that it is the defining principle. 有太多的“框架”，不要使用IoC来说它是定义原则。 A search for embedded or micro controller frameworks reveals a whole plethora which do NOT use IoC and I now believe that the .Net language and CLR is an acceptable descendant of the "general" framework. 对嵌入式或微控制器框架的搜索揭示了不使用IoC的全部过多而我现在认为.Net语言和CLR是“通用”框架的可接受的后代。 To say that IoC is the defining characteristic is simply too rigid for me to accept I'm afraid, and rejects out of hand anything putting itself forward as a framework which matches the historical representation as mentioned above. 说IoC是一个定义的特征，对我来说太过刻板，我害怕接受，并且拒绝任何将自己作为一个与上述历史表征相匹配的框架。

For details of non-IoC frameworks, see, as mentioned above, many embedded and micro frameworks, as well as any historical framework in a language that does not provide callback through the language (OK. Callbacks can be hacked for any device with a modern register system, but not by the average programmer), and obviously, the .net framework. 有关非IoC框架的详细信息，请参阅上面提到的许多嵌入式和微型框架，以及不通过该语言提供回调的语言中的任何历史框架（OK。回调可以被任何具有现代功能的设备攻击注册系统，但不是普通的程序员），显然，.net框架。

#3楼

It's a little bit subjective I think. 我认为这有点主观。 The toolkit is the easiest. 该工具包是最简单的。 It's just a bunch of methods, classes that can be use. 它只是一堆方法，可以使用的类。
The library vs the framework question I make difference by the way to use them. 库与框架问题我通过使用它们的方式有所不同。 I read somewhere the perfect answer a long time ago. 很久以前我在某处读到了完美的答案。 The framework calls your code, but on the other hand your code calls the library. 框架调用您的代码，但另一方面您的代码调用库。

#4楼

Framework: installed on you machine and allowing you to interact with it. 框架：安装在您的机器上并允许您与它进行交互。 without the framework you can't send programming commands to your machine 没有框架，您无法向您的机器发送编程命令

Library: aims to solve a certain problem (or several problems related to the same category) 图书馆：旨在解决某个问题（或与同一类别相关的几个问题）

Toolkit: a collection of many pieces of code that can solve multiple problems on multiple issues (just like a toolbox) 工具包：可以解决多个问题的多个问题的许多代码集合（就像工具箱一样）

#5楼

Library 图书馆

I think it's unanimous that a library is code already coded that you can use so as not to have to code it again. 我认为一致的是，库是已编码的代码，您可以使用它，以便不必再次编码。 The code must be organized in a way that allows you to look up the functionality you want and use it from your own code. 必须以允许您查找所需功能并从您自己的代码中使用它的方式组织代码。

Most programming languages come with standard libraries, especially some code that implements some kind of collection. 大多数编程语言都带有标准库，特别是一些实现某种集合的代码。 This is always for the convenience that you don't have to code these things yourself. 这总是为了方便您不必自己编写这些东西。 Similarly, most programming languages have construct to allow you to look up functionality from libraries, with things like dynamic linking, namespaces, etc. 类似地，大多数编程语言都有构造，允许您从库中查找功能，包括动态链接，命名空间等。

So code that finds itself often needed to be re-used is great code to be put inside a library. 因此，经常需要重新使用的代码是很好的代码，可以放在库中。

Toolkit 工具包

A set of tools used for a particular purpose. 用于特定目的的一组工具。 This is unanimous. 这是一致的。 The question is, what is considered a tool and what isn't. 问题是，什么被认为是一种工具，什么不是。 I'd say there's no fixed definition, it depends on the context of the thing calling itself a toolkit. 我会说没有固定的定义，它取决于自称为工具包的东西的上下文。 Example of tools could be libraries, widgets, scripts, programs, editors, documentation, servers, debuggers, etc. 工具示例可以是库，小部件，脚本，程序，编辑器，文档，服务器，调试器等。

Another thing to note is the "particular purpose". 另一件需要注意的是“特殊目的”。 This is always true, but the scope of the purpose can easily change based on who made the toolkit. 这始终是正确的，但目的范围可以根据制作工具包的人员轻松更改。 So it can easily be a programmer's toolkit, or it can be a string parsing toolkit. 所以它很容易成为程序员的工具包，或者它可以是一个字符串解析工具包。 One is so broad, it could have tool touching everything programming related, while the other is more precise. 一个是如此广泛，它可以让工具接触与编程相关的所有内容，而另一个更精确。

SDKs are generally toolkits, in that they try and bundle a set of tools (often of multiple kind) into a single package. SDK通常是工具包，因为它们尝试将一组工具（通常是多种工具）捆绑到一个包中。

I think the common thread is that a tool does something for you, either completely, or it helps you do it. 我认为共同的思路是一个工具可以完全为你做点什么，或者它可以帮助你做到。 And a toolkit is simply a set of tools which all perform or help you perform a particular set of activities. 工具包只是一组工具，可以执行或帮助您执行一组特定的活动。

Framework 骨架

Frameworks aren't quite as unanimously defined. 框架不是一致定义的。 It seems to be a bit of a blanket term for anything that can frame your code. 对于可以构建代码的任何内容来说，它似乎都是一个笼统的术语。 Which would mean: any structure that underlies or supports your code. 这意味着：任何基础或支持您的代码的结构。

This implies that you build your code against a framework, whereas you build a library against your code. 这意味着您要针对框架构建代码，而针对代码构建库。

But, it seems that sometimes the word framework is used in the same sense as toolkit or even library. 但是，有时单词框架的使用方式与工具包甚至库相同。 The .Net Framework is mostly a toolkit, because it's composed of the FCL which is a library, and the CLR, which is a virtual machine. .Net Framework主要是一个工具包，因为它由作为库的FCL和作为虚拟机的CLR组成。 So you would consider it a toolkit to C# development on Windows. 所以你会认为它是Windows上C＃开发的工具包。 Mono being a toolkit for C# development on Linux. Mono是Linux上C＃开发的工具包。 Yet they called it a framework. 然而他们称之为框架。 It makes sense to think of it this way too, since it kinds of frame your code, but a frame should more support and hold things together, then do any kind of work, so my opinion is this is not the way you should use the word. 以这种方式思考也是有道理的，因为它构成了你的代码框架，但框架应该更多地支持并将事物放在一起，然后做任何工作，所以我认为这不是你应该使用的方式字。

And I think the industry is trying to move into having framework mean an already written program with missing pieces that you must provide or customize. 而且我认为业界正试图让框架意味着一个已编写的程序，缺少必须提供或定制的部分。 Which I think is a good thing, since toolkit and library are great precise terms for other usages of "framework". 我认为这是一件好事，因为工具包和库是“框架”其他用法的精确术语。

#6楼

very, very similar, a framework is usually a bit more developed and complete then a library, and a toolkit can simply be a collection of similar librarys and frameworks. 非常非常相似，框架通常比库更加开发和完善，而工具包可以简单地是类似的库和框架的集合。

a really good question that is maybe even the slightest bit subjective in nature, but I believe that is about the best answer I could give. 一个非常好的问题，甚至可能是最微小的主观性质，但我相信这是我能给出的最佳答案。