指令式编程 VS 声明式编程

概括地说，我们可以有两种编写代码的方式：指令式和声明式。

我们可以定义如下：

指令式编程：告诉机器该如何做，并得到自己想要的结果。
声明式编程：告诉机器您想得到什么，让机器自己计算该如何做。

指令式编程和声明式编程的例子

举一个简单的例子，假设我们想让数组中的每个值变为原来的2倍。

指令式编程的代码可以如下：

复制代码var numbers = [1,2,3,4,5]
var doubled = []

for(var i = 0; i < numbers.length; i++) {
  var newNumber = numbers[i] * 2
  doubled.push(newNumber)
}
console.log(doubled) //=> [2,4,6,8,10]

我们遍历整个数组，取出每个元素，乘以2，然后把新值放到新数组中，直到完成。

一种声明式的编程方式可以使用Array.map，如下：

复制代码var numbers = [1,2,3,4,5]

var doubled = numbers.map(function(n) {
  return n * 2
})
console.log(doubled) //=> [2,4,6,8,10]

map根据旧数组返回新的数组，在这个例子中，通过把旧数组中的元素传入到map (function(n) { return n*2 }中，返回一个新数组，新数组的每个值都是相对应的旧数组的值的2倍。

map函数的作用是抽象出遍历数组的过程，让我们更关注于我们想得到什么。注意，我们传入到map中的函数是纯净的。不能有任何副作用（改变其他额外的状态），它只是拿到一个数，并把它变成2倍。

对于数组，这里还有其他一些常见的声明式抽象函数。比如说，为了对数组中所有的元素求和，我们可以这么做：

复制代码var numbers = [1,2,3,4,5]
var total = 0

for(var i = 0; i < numbers.length; i++) {
  total += numbers[i]
}
console.log(total) //=> 15

或者我们可以使用声明式函数reduce：

复制代码var numbers = [1,2,3,4,5]

var total = numbers.reduce(function(sum, n) {
  return sum + n
}, 0);
console.log(total) //=> 15

reduce利用给定的函数将数组遍历计算出一个值。它将这个函数应用到数组中的每个元素。在每次调用中，第一个参数（例子中的sum）是前一个元素调用函数后得出的结果，第二个参数（n）是当前元素。所以，在这个例子中，每一步，都把当前数组元素n加到sum中，这样，最后我们就能得到整个数组的和。

同样，reduce为我们抽象了循环遍历和状态管理方面的事情，给了我们遍历数组计算出一个值的通用方法。我们需要做的就是明确我们想要什么。

很奇怪？

我保证，如果您之前没见过map或者reduce，您一定会感觉到奇怪。作为程序员，我们总是很习惯指定如何让事情发生，“遍历数组”，“如果怎么样然后怎么样”，“用新值更新这个变量”。既然我们已经知道如何告诉机器该怎么做，为什么还要学习这个看起来有点奇怪的抽象呢？

在许多情况下，指令式代码是好的。当我们编写业务逻辑时，我们通常不得不编写大部分必需的代码，因为在我们的业务逻辑中不存在更通用的抽象。

但是如果我们花时间去学习（或构建！）声明式的抽象方法，在编写代码时，我们就可以使用一些强大的快捷方式。首先，我们通常会写得越来越少，这是一个速见成效的胜利。然后，我们也可以在一个更高的层次思考问题，站在云端思考我们想要发生什么，而不是陷在泥里思考如何使它发生。

SQL

您可能没有意识到，但是在SQL中，您已经使用过声明式编程了。

您可以把SQL看作一种用于处理数据集的声明式查询语言。您是否用SQL写过整个应用？可能没有。但是对于处理相关联的数据集，它会非常强大。

做一个查询：

1
2
3

复制代码SELECT * from dogs
INNER JOIN owners
WHERE dogs.owner_id = owners.id

想象一下您用指令式编程来写这段逻辑：

复制代码//dogs = [{name: 'Fido', owner_id: 1}, {...}, ... ]
//owners = [{id: 1, name: 'Bob'}, {...}, ...]

var dogsWithOwners = []
var dog, owner

for(var di=0; di < dogs.length; di++) {
  dog = dogs[di]

  for(var oi=0; oi < owners.length; oi++) {
    owner = owners[oi]
    if (owner && dog.owner_id == owner.id) {
      dogsWithOwners.push({
        dog: dog,
        owner: owner
      })
    }
  }}
}

我并不是说SQL很容易理解，或者当您第一次看到时就很轻松地明白它，但是相比于那段复杂的代码，它已经简洁很多了。

但是它不仅更简短而且更容易阅读，SQL还给了我们许多其他好处。因为我们已经抽象了具体的实现方法，我们可以只关注我们想要什么，然后让数据库优化具体实现步骤。

如果我们没有使用它，我们自己的代码将会很慢，因为我们必须要为列表中的每只dog遍历整个owners数组。

但是在SQL代码的例子中，我们可以让数据库来自己实现如何返回给我们正确的结果。如果使用索引有意义（假设我们已经建立了），数据库就会这么做，这会提升很大的性能。如果此次查询在一秒前就执行过，就可以直接从缓存中读取。通过放手让计算机自己决定实现方式，我们只需要稍微改变一下认知，就可以得到巨大的好处。

d3.js

另外一个能体现出声明式编程好处的地方在用户界面、图表和动画。

编写用户界面是一件很困难的事。因为我们有用户交互，想要做好用户交互，我们通常会有很多的状态管理和指令式代码，其实这些都可以被抽象出来，但通常并没有。

一个很好的声明式抽象的例子是d3.js。通过使用JavaScript和SVG（大部分），d3这个库可以帮我们创建交互式的，带动画的可视化数据。

第一次（第五次，甚至第十次）您看到或尝试写d3代码，您可能都会头痛。就像SQL一样，d3几乎封装了所有您可能用到的处理可视化数据的方法，让您只关注您想得到什么。

这里有一个例子（我建议大家看一下这个例子，了解下上下文）。这个d3图表是根据data数组中的每个对象画一个圆。为了展示发生了什么，我们每秒钟加一个圆。

有趣的代码是：

复制代码//var data = [{x: 5, y: 10}, {x: 20, y: 5}]

var circles = svg.selectAll('circle')
                    .data(data)

circles.enter().append('circle')
           .attr('cx', function(d) { return d.x })
           .attr('cy', function(d) { return d.y })
           .attr('r', 0)
        .transition().duration(500)
          .attr('r', 5)

没有必要弄清这里究竟发生了什么（不管怎样，你都需要一段时间才能清醒过来），但要点是这样的：

首先我们选取所有的circlesvg（初始的时候没有）。然后给它们绑定一些数据。

D3持续追踪哪个数据点被绑定到图表中哪个圆上。所以开始的时候我们有两个数据点，但是没有圆；然后我们可以使用.enter()方法来获取已经“进入”的数据点。对于这些点，我们想对应地将一个圆加入到图表中，以数据的x和y为圆心，初始半径为0，但是0.5s后渐变到半径为5。

这为什么有趣？

再来看一下代码，并思考我们是否描述了我们想要什么样的可视化图表，或者是否怎样来画？您会发现，几乎没有怎样画的代码出现。我们只是描述了我们想要什么：

我想要把这个数据画成圆，圆心由数据指定。并且如果有新的圆，就加进来，且半径要有动画。

这很神奇，我们没有写一个循环，也没有写状态管理。编写图表通常是困难和麻烦的，但是d3已经为我们做了大部分封装，我们只需要明确我们想要什么即可。

现在d3.js易懂了吗？并没有，它肯定要花一段时间来学习。并且您大部分要学习的是放弃指定事情如何发生，而是要学习如何明确您想要什么。

刚开始的时候，这很困难，但是经过几个小时后，神奇的事情发生了——您会越来越有效率。通过封装具体实现方式，d3.js真正地让您关注您想看到什么，并且这也是当您实现可视化时只需要关注的。它把您从繁琐的细节中解放出来，让您以一个更高的水平思考问题，打开了创造的可能性。

最后

声明式编程允许我们描述我们想要的，让底层软件/计算机等来处理具体如何实现。

正如所见，很多时候，这可以让我们在写代码方面得到提高，不仅是更少的代码行数，或者性能，而且高抽象的编码方式使我们能更关注于我们想要什么，这正是我们作为问题解决者真正该关心的。

问题是，过去我们已经习惯于指令式编程。它使我们感觉舒服和自然，甚至强大（能够控制它是怎么发生的），不肯将具体实现方式交给我们看不到或者不理解的程序。

有时候，编写具体实现方式是可以的。如果我们需要微调代码来提高性能，我们可能需要更细节地指明如何实现。或者对于业务代码，本身就没有什么可以抽象封装的地方，我们就得编写指令式代码。

但是，我们可以（并且应该）经常寻找声明性的方法来编写代码，如果找不到，我们应该构建它们。这在开始的时候会很困难吗？是的，几乎可以肯定！但正如我们看到的SQL和d3.js，长期收益是巨大的！

本文转载自: 掘金

开发者博客 – 和开发相关的这里全都有