如何理解闭包这一概念

     维基百科上对闭包的解释就很经典：在计算机科学中，闭包（Closure）是词法闭包（Lexical Closure）的简称，是引用了自由变量的函数。这个被引用的自由变量将和这个函数一同存在，即使已经离开了创造它的环境也不例外。所以，有另一种说法认为闭包是由函数和与其相关的引用环境组合而成的实体。Peter J. Landin 在1964年将术语闭包定义为一种包含环境成分和控制成分的实体。

先看看数学上的闭包。

(1,5) 是一个区间，但对这个区间做分析、计算什么的，经常会用到1和5这两个不属于这个区间的值，[1,5]就是(1,5)的闭包。

在生活上，我们办事情，找A部门，A部门说，你先得找B部门盖个章，B部门说，你先得找C部门盖个章，C部门说，这个东西不是我们的职权范围…… 踢皮球，这就是非闭包。闭包就是负责到底，你找到A部门，A部门接待的那个人负责到底，他/她去协调B部门和C部门。

在工程上，闭包就是项目经理，负责调度项目所需要的资源。老板、客户有什么事情，直接找项目经理即可，不用再去找其它的人。

在程序语言中，闭包就是一种语法糖，它以很自然的形式，把我们的目的和我们的目的所涉及的资源全给自动打包在一起，以某种自然、尽量不让人误解的方式让人来使用。至于其具体实现，我个人意见，在不影响使用的情况下，不求甚解即可。在很多情况下，需要在一段代码里去访问外部的局部变量，不提供这种语法糖，需要写非常多的代码，有了闭包这个语法糖，就不用写这么多代码，自然而然的就用了。

这样一来，可以把闭包从一个语法机制提升为一种设计原则：闭包是从用户角度考虑的一种设计概念，它基于对上下文的分析，把龌龊的事情、复杂的事情和外部环境交互的事情都自己做了，留给用户一个很自然的接口。

在这个原则下，函数式语言中，那种所谓的闭包只是一种“闭包”，还有大量的其它类型的“闭包”等待发现和实现。

下面举出一些闭包设计原则的正例和反例。

总结：

1. 闭包是一种设计原则，它通过分析上下文，来简化用户的调用，让用户在不知晓的情况下，达到他的目的；
2. 网上主流的对闭包剖析的文章实际上是和闭包原则反向而驰的，如果需要知道闭包细节才能用好的话，这个闭包是设计失败的；
3. 尽量少学习。