指令式编程 VS 声明式编程

时间: 2017-12-11阅读: 168标签: 编程

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

我们可以定义如下:

  • 指令式编程:告诉机器该如何做,并得到自己想要的结果。

  • 声明式编程:告诉机器您想得到什么,让机器自己计算该如何做。


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

举一个简单的例子,假设我们想让数组中的每个值变为原来的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写过整个应用?可能没有。但是对于处理相关联的数据集,它会非常强大。

做一个查询:

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,长期收益是巨大的!