Promise并不是一个新的概念,它已经有将近30年的历史.

其早期的雏形还有里氏替换原则的提出者Barbara Liskov的贡献在其中.

https://en.wikipedia.org/wiki/Futures_and_promises#History

而Promises/A+这个规范的出现,则为JavaScript世界中众多Promise实现库提供了一套统一的API和交互机制.

Promises/A+提供了配套的测试集:https://github.com/promises-aplus/promises-tests.

其中共有872个测试,如果你的实现能够让全部测试绿起来,则可以认为该实现符合了标准.

背景

Wifi，4G，3G，这些我们习以为常的东西，未必对所有人来说都是随时可用的。

以我当前所在项目为例，应用场景是某欠发达地区医疗服务机构的药品库存管理。

所谓欠发达，具体怎样呢？

• 没有台式电脑
• 没有笔记本
• 只能使用低端的安卓平板
• 4G，3G信号不要想
• 我们去过现场的一位同事甚至要爬到树上去，才能勉强收到2G信号
  
• 即便是2G信号，也是时断时续，非常不稳定

因此，需要随时保持连通的BS结构基本不可行，我们选择了重度依赖移动端设备本地存储的CS结构（胖客户端）。

2015年结束了，一如已经结束了的每一年，非常迅速。

按惯例，从博客说起。

博客

15年写了16篇博客，其中9篇是与Scala，Reactive，OODP相关的。这个数字倒还不算太坏。

14年总结的时候说：

明年可以改进的是不要嫌话题小，不要嫌话题不够深。 有了有价值的想法就记下来，形成惯性。

惨。

八月份上了一个大客户的项目，到了晚上没力气也没心情做任何事情。

博客

没写。上个季度六月的系列告一段落后7月没写。到了8月就不用说了。

读书

七月八月读了7本书，9月一本未读。

2015竟然这么快就过去一半了。逝者如斯夫。

博客

第一季度总结的时候说：

今年的博客主线任务定为OO与FP的比较和结合应用吧。

这个任务完成的不错，这个主题写了7篇博客。

迭代器已经irrelevant了，中介者和备忘录太简单就没写，状态模式没找到好的FP实现方式。
这样11种行为模式除去上述4个，算是基本覆盖完了。

模板方法模式定义了一个算法的步骤，并允许次类别为一个或多个步骤提供其实践方式。让次类别在不改变算法架构的情况下，重新定义算法中的某些步骤。

以上是wiki对模板方法的定义。

比较容易理解，我们有一个算法，其中某些步骤是确定的不太会变的代码。而另外一些步骤则需要变化并且自由组合。

《Head First Design Patterns》里有一个🌰：

假设我们需要制作咖啡因饮品，其实就是咖啡和茶。制作步骤有些类似，分为四步：1烧水，2泡，3装杯，4加调料。

其中第一步和第三步是稳定的代码，变化可能性不大，而第二步和第四步则每种饮品有自己的风味。

访问者模式是一种将算法与对象结构分离的软件设计模式。

这个模式的基本想法如下：首先我们拥有一个由许多对象构成的对象结构，这些对象的类都拥有一个accept方法用来接受访问者对象；访问者是一个接口，它拥有一个visit方法，这个方法对访问到的对象结构中不同类型的元素作出不同的反应；在对象结构的一次访问过程中，我们遍历整个对象结构，对每一个元素都实施accept方法，在每一个元素的accept方法中回调访问者的visit方法，从而使访问者得以处理对象结构的每一个元素。我们可以针对对象结构设计不同的实在的访问者类来完成不同的操作。

以上是wiki对访问者模式的定义。

这个定义着实难读。我们来看wiki给出的例子：

假设我们要为汽车建模，汽车有不同的组成部件，轮胎，车身，和引擎。

在开车之前需要先检查车辆每个部件的状况，然后依次启动所有部件以启动汽车。

观察者模式

观察者模式（有时又被称为发布/订阅模式）是软件设计模式的一种。在此种模式中，一个目标对象管理所有相依于它的观察者对象，并且在它本身的状态改变时主动发出通知。这通常透过呼叫各观察者所提供的方法来实现。此种模式通常被用来实作事件处理系统。

以上是wiki对观察者模式的解释。

举一个《Head first design pattern》中的例子：

比如说有一个气象站，每当气象有变化的时候就需要显示当前天气。
需要显示历史平均气温，最高气温和最低气温。
还需要根据气压预测晴雨。

这种情况就很适合使用观察者模式，每种需要显示气象的装置作为观察者，气象数据本身作为可以被观察的对象。
每当气象变化的时候，被观察的对象就会通知观察者来根据新的数据作出新的显示。

解释器模式

In computer programming, the interpreter pattern is a design pattern that specifies how to evaluate sentences in a language. The basic idea is to have a class for each symbol (terminal or nonterminal) in a specialized computer language. The syntax tree of a sentence in the language is an instance of the composite pattern and is used to evaluate (interpret) the sentence for a client.

以上是wiki对解释器模式的描述。

这是一个学术性稍强的模式，不太好找到生活化的比喻。

就直接上代码吧。

Java

命令模式

在面向对象程式设计的范畴中，命令模式是一种设计模式，它尝试以物件来代表实际行动。命令物件可以把行动(action) 及其参数封装起来，于是这些行动可以被：

• 重复多次
• 取消（如果该物件有实作的话）
• 取消后又再重做

以上是wiki对命令模式的定义（术语像是台湾的）。

下面是来自《Head first design patterns》的一个例子：

假设你有很多家用电器：电灯泡，电视，音响，还有一个水疗浴缸。（就是没有手电筒）

职责链模式

责任链模式在面向对象程式设计里是一种软件设计模式，它包含了一些命令对象和一系列的处理对象。每一个处理对象决定它能处理哪些命令对象，它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。该模式还描述了往该处理链的末尾添加新的处理对象的方法。

以上是wiki对职责链模式的定义。

举个例子来说，我们的系统中需要记录日志的功能。日志需要根据优先级被发送到不同的地方。

低优先级的日志输出到命令行就好了。而高优先级的错误信息则需要通过邮件通知相关人员并且输出到命令行。

这个例子也是来自wiki的。

策略模式

策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法。

以上是中文wiki中对策略模式的定义。

In computer programming, the strategy pattern (also known as the policy pattern) is a software design pattern that enables an algorithm’s behavior to be selected at runtime. The strategy pattern:

• defines a family of algorithms,
• encapsulates each algorithm, and
• makes the algorithms interchangeable within that family.

Strategy lets the algorithm vary independently from clients that use it.

声明

这系列博文的目标读者仅限于报名参加了这门课并且看完了视频，看完了作业的instruction之后仍有困难的同学。

这系列博文不会公布作业的答案，那是违反Coursera的code of honor的。

我只会试着解释作业中已有的代码，以及应该如何入手。

其实，写这个系列博文对我的帮助比对读者的帮助要大。

这周的作业不太难，主要就是一个观察者模式。

#前尘
Principles of Reactive Programming在4月13号又开课了。
https://www.coursera.org/course/reactive

上次开课是在2013年的11月，当时我刚第一次上完Functional programming principles in Scala，热情很高于是就报名参加了这门课。
还群发了一个邮件找人一起上课。

但是上了几周发现有点难，于是就放弃了。现在去bitbucket看，最后一次push停留在了2013-11-18。

后来还在上海被8x鄙视于无形之中。

后世

14年做了几个月的Scala开发，后来Functional programming principles in Scala再次开课又上了一遍，拿了个认证证书。

源起

前两天，在一个武汉本地程序员聚集的技术社区微信群里某位群友发了两张图片：

这是某个IT公司的招聘宣传，为程序员提供的鼓励师。

（由于图片出现在愚人节期间，不确定该公司是真的有这样的人员配备，还是恶作剧的，此处暂且存疑）

时间是以何种方式流逝的呢？

三个月瞬间就不见了。

对照着去年的总结和当时对未来的期望写一下2015年第一季度吧。

博客

惨不忍睹。

除了一个应付任务的tech radar的session写在了博客上，其他啥都没写。

2014年即将结束，需要做一些总结。

既然总结是写在博客上的，第一项就先说博客吧。

博客

2014年写了18篇博客，其中15篇和Scala有关，自认为都是有且仅有干货的。

对此，我比较_满意_。

不过这个数字存在欺骗性，15篇Scala的博客，其中4篇写于1月份，6篇写于6月份，其余的零散的写就与其他月份。

大家都知道Scala标准库的List有一个用来做聚合操作的foldLeft方法。

比如我定义一个公司类：

1

case class Company(name:String, children:Seq[Company]=Nil)

它有名字和子公司。
然后定义几个公司：

1

val companies = List(Company("B"),Company("A"),Company("T"))

三家大公司，然后呢，我假设有一家超牛逼的公司把它们给合并了：

假设一个场景

需要在50个随机数中找到前两个可以被3整除的数字。

听起来很简单，我们可以这样来写：

1
2
3
4
5
6
7
8
9

def randomList = (1 to 50).map(_ => Random.nextInt(100)).toList

def isDivisibleBy3(n: Int) = {
  val isDivisible = n % 3 == 0
  println(s"$n $isDivisible")
  isDivisible
}

randomList.filter(isDivisibleBy3).take(2)

一个产生50个随机数的函数；

一个检查某数字是否能被3整除的函数；

Scala里的for关键字是个很有趣的东西。可以用来把多层嵌套for循环写成一层。比如这样：

1

for(i<-1 to 10;j<-1 to 10;k<-1 to 10) yield(s"$i $j $k")

这行代码执行的结果是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

1 1 1
1 1 2
1 1 3
1 1 4
1 1 5
1 1 6
1 1 7
1 1 8
1 1 9
1 1 10
1 2 1
1 2 2
1 2 3
1 2 4
1 2 5
1 2 6
1 2 7
1 2 8
1 2 9
1 2 10
......
......

这样，就可以用一行代码写出三层循环的效果。代码看起来非常紧凑，噪音很少。

但是今天主要要说的不是这种for，而是它和Option结合的写法。