框架和库之间的区别是什么?
我一直认为库是一组对象和函数,专注于解决特定的问题或应用程序开发的特定领域(即数据库访问);另一方面,框架是一个以特定方法论(即MVC)为中心的库的集合,它涵盖了应用程序开发的所有领域。
框架和库之间的区别是什么?
我一直认为库是一组对象和函数,专注于解决特定的问题或应用程序开发的特定领域(即数据库访问);另一方面,框架是一个以特定方法论(即MVC)为中心的库的集合,它涵盖了应用程序开发的所有领域。
当前回答
根据Erich Gamma等人在《设计模式》一书中给出的定义:
库:构成可重用实现的一组相关过程和类; 框架:由一组具有模板方法的协作类组成的可重用规范。它设置了控制流,并允许通过在子类中重写框架类中模板方法调用的钩子方法来将框架裁剪到特定问题的流中。
特定于问题的代码可以使用库和实现框架。
其他回答
什么是图书馆?
库是代码块的集合(可以是变量、函数、类、接口等形式),由开发人员构建,以简化其他发现其相关性的开发人员的软件开发过程。
什么是框架?
参考库的定义,我们可以将框架定义为一种工具,通过在受控的开发环境中为开发人员提供必要的库,帮助开发人员解决大量特定于领域的问题。
我喜欢科恩的回答,但更专业的定义是:你的代码调用一个库。框架调用您的代码。例如,GUI框架通过事件处理程序调用代码。web框架通过请求-响应模型调用你的代码。
这也被称为控制反转——突然之间,框架决定何时以及如何执行你的代码,而不是像库那样反过来执行。这意味着框架对代码的结构也有更大的影响。
我忘记在哪里看到这个定义了,但我觉得它很好。
库是从代码中调用的模块,框架是调用代码的模块。
我会像你五岁一样解释。(没有使用编程术语。)
让我们想象一下,你不久前在你的城市开了一家汉堡店。但是作为初学者,你会觉得做汉堡太难了。你在想一种为顾客做汉堡的简单方法。 有人告诉你,如果你使用框架,你可以很容易地做bugger。你要知道有麦当劳汉堡框架和汉堡王汉堡框架。
如果你使用麦当劳汉堡框架,做巨无霸汉堡就很容易了。(但你不能做皇堡。)
如果你使用汉堡王汉堡框架,就可以很容易地做出皇堡。(但是你不能做巨无霸)
不管怎样,最后,它们都是汉堡。这里很重要的一点是,你必须遵循他们的框架规则来做汉堡。否则,你会觉得更难完成或者根本无法完成。
你也听说过有一种叫做简单汉堡-帕蒂图书馆的东西。
如果你使用这个库,你可以很容易地做出任何汉堡肉饼(X2速度)。 使用麦当劳汉堡框架还是汉堡王汉堡框架并不重要。 无论哪种方式,您仍然可以使用这个简单汉堡-帕蒂库。(即使你没有框架也可以使用这个库。)
你现在看到框架和库的区别了吗?
一旦你开始使用麦当劳汉堡框架。要切换到汉堡王的汉堡框架并不容易。既然你要把整个厨房都换了。
如果您开始使用Java Spring框架构建Web应用程序,那么稍后将很难(也许不可能)更改为Ruby on Rails框架。
但是Library,换别人会容易得多。或者你可以不用它。
实际上,这取决于你给术语下什么定义。可能有很多不同的定义。
我认为下面的解释是基于我认为这个术语指的是什么:
确定的图书馆
确定性库保存的函数是基于A)函数输入或b)在函数调用之间以某种方式维护的状态确定的。
如果将逻辑依赖注入确定性库,则该逻辑必须符合具体的规范,以便库的输出不受影响。
示例:一个碰撞检测库,由于某种原因依赖于排序函数来帮助这些计算。这个排序函数可以配置为优化目的(例如通过依赖注入,编译时链接等),但必须始终符合相同的输入/输出映射,以便库本身保持确定性。
非命定论的图书馆
一个非确定性库可以通过与它以某种方式访问的其他外部非确定性库通信来保存非确定性函数。
我通常将不确定性库称为服务。
示例:依赖于随机数字生成器服务来洗牌的扑克库。这可能是一个不好的例子,因为出于架构的目的,我们应该将这个库的不确定性方面推到外部。相反,通过采用预先洗牌的牌组,扑克库可以变得具有确定性和单元可测试性,现在这个库的用户有责任随机洗牌,如果他们愿意的话。
框架
框架介于确定性库和非确定性库之间。
任何依赖注入框架的逻辑在该函数实例的生命周期内都必须是确定的,但是不同逻辑的不同函数实例可以被注入到框架函数的单独执行中。
Example: Functions that operate on lists such as map, filter, sort, reduce, that expect to take in functions that are deterministic but can have varying logic for different executions. Note that this requirement only exists if these list operations advertise themselves as deterministic. In most languages, list operations wouldn't have this constraint. The core logic of such frameworks are deterministic, but are allowed to accept indeterministic logic at the risk of the user. This is generally a messy scenario to deal with, because output can vary widely due to implementation details of the framework.