本文的目的是为了总结下我在开发者大会上看傅若愚做的演讲。因为大会的时间比较短，所以，他并没有足够的时间来解释清楚他是如何解决回调地狱的。我后续请教了他，他用下面非常清晰思维过程做了回复！
再此，非常感谢@傅若愚的耐心指导，大家有空也一定要看一看@swift开发者大会的相关视频，一定会收货颇多。
以下内容基本出自他的讲义，以及他对我提的问提“为什么使用这种方式解决回调地狱的思考过程”的回复。
抽象这个过程
Hmmmm，为什么我们会想到用Async来简化回调地狱呢？我们得回头想想所谓的回调地狱到底是怎么一回事，首先一起来看一段相对简单的“回调地狱”吧（为了简单起见，我们先不考虑错误处理）：
getFirstItem() {
firstItem in getSecondItem(firstItem) {
secondItem in getThirdItem(secondItem){
thirdItem in
//Here we get our third item
}
}
}
所以它到底是在干什么？如果我们将它按照人类的语言描述一遍，并尽量不遗漏掉任何的代码执行过程：
1、异步地发出一个请求，在回调中获得请求的数据。（即firstItem）然后根据上一步的数据，在getSecondItem中计算出一个新的请求。
2、异步地发出这个新的请求，并在回调中获得请求的数据。（即secondItem）然后根据上一步的数据，在getThirdItem中计算出一个新的请求。
3、异步地发出这个新的请求，并在回调中获得请求的数据。（即thirdItem）
分析这个过程
于是我们可以看到，所谓的“回调地狱”其实也不过是在重复地做一些计算的过程，如果我们能够找到一种对类似的计算过程的封装方法，那么我们就能解决“回调地狱”的问题。
这里如果直接去想，去找，真的是挺难的，原因在于我们平时写代码其实更多地是在对数据进行抽象：比如我们会去抽象一个用户，一个商品——这些东西都是一个一个的对象（或者说封装之后的数据），即便涉及到对象的方法，那本质上也是在对数据的行为进行的抽象。而现在，我们却是需要对一种计算的过程进行抽象，它需要的编程思维和我们平时所习惯的代码写法完全是不一样的！
想想是否有现有的模式去解决这个问题
那么，有没有类似的已经做出来的其他过程抽象的例子可以给我们参考，帮助我们进行思考呢？答案当然是有的，并且不止一个！如果对Swift的标准库比较熟悉，那么很容易想到Optional.flatMap这个函数:
public enum Optional<Wrapped> : _Reflectable, NilLiteralConvertible {
case None
case Some(Wrapped)
/// Construct a `nil` instance.
public init()
/// Construct a non-`nil` instance that stores `some`.
public init(_ some: Wrapped)
/// If `self == nil`, returns `nil`. Otherwise, returns `f(self!)`.
@warn_unused_result
public func map<U>(@noescape f: (Wrapped) throws -> U) rethrows -> U?
/// Returns `nil` if `self` is nil, `f(self!)` otherwise.
@warn_unused_result
public func flatMap<U>(@noescape f: (Wrapped) throws -> U?) rethrows -> U?
/// Create an instance initialized with `nil`.
public init(nilLiteral: ())
}
这个函数的具体用法如下：
someOptionalNumber
.flatMap(divide3) //{x in x == 0 ? nil : return 3/x}
.flatMap(divide5) //{x in x == 0 ? nil : return 5/x}
//我们还可以无限地链下去......
如果我们把上面这段代码像之前那样描述一遍：
1、对一个Optional数据，确保这个数据的值不为nil，否则后面的步凑不执行。然后根据上一步的数据，在divide3中计算出一个新的Optional数据。
2、对这个新的Optional数据，确保这个数据的值不为nil，否则后面的步凑不执行然后根据上一步的数据，在divide5中计算出一个新的Optional数据。
3、对这个新的Optional数据……
终于找到了这个计算过程
我们发现，这个过程竟然与我们此前的描述很多部分惊人的相似！
然后根据上一步的数据，在XXX中计算出一个新的XXXX。
这句话似乎应该是一个pattern，如果它是一个pattern，肯定不止会在一个地方出现！于是我们再来看看这个我们可能更加熟悉的函数！
[1,2,3,4,5]
.flatMap(duplicate) // { x in return [x, x] }
.flatMap(anotherFunction) // {x in return [x, x]}
//[1,1,1,1,2,2,2,2,3,3,3,3,4,4,4,4,5,5,5,5]
老办法，把它真正做的事情翻译一遍，并尽量不遗漏任何计算过程：
遍历一个Array，得到其中的每一个数据然后根据上一步的数据，在duplicate中计算出一个新的Array
遍历这个新的Array，得到其中的每一个数据然后根据上一步的数据，在anotherFunction中计算出一个新的Array
......
果然出现了！如果我们现在再根据上下文回去看我们“回调地狱”的问题，我们可以确信，只要我们将这个步骤封装好了，我们的问题也就解决了！并且我们所需要做的事情仅仅是定义一个针对回调函数的flatMap而已。首先，让我们把一个异步函数封装进一个结构体，什么是异步函数呢？比如：
func async(callback: String->Void){}
这就是一个异步函数，它的签名是 (String->Void)->Void的形式。那么我们首先将形如
(T->Void)->Void的函数封装起来：
struct Async<T>{ let asyncFunction:(T->Void)->Void}
接下来，我们观察Optional和Array的flatMap函数:
//Optional 的 flatMap函数定义
/// Returns `nil` if `self` is nil, `f(self!)` otherwise.
@warn_unused_result
public func flatMap<U>(@noescape f: (Wrapped) throws -> U?) rethrows -> U?
如果不知道@noescape，throws，rethrows，去掉无妨阅读，比如，这样理解
public func flatMap<U>( f: (Wrapped) throws -> U?) -> U?
是不是更加清晰了
//Array 的 flatMap函数定义
extension SequenceType {
/// Return an `Array` containing the non-nil results of mapping
/// `transform` over `self`.
///
/// - Complexity: O(*M* + *N*), where *M* is the length of `self`
/// and *N* is the length of the result.
@warn_unused_result
public func flatMap<T>(@noescape transform: (Self.Generator.Element) throws -> T?) rethrows -> [T]
}
同理：去掉@noescape等等干扰
public func flatMap<T>(transform: (item) -> T?) -> [T]
他们的函数签名几乎一模一样：
flatMap<U>(transform:T -> M<U>) -> M<U> //其中M<U>表示Array<U>或者Optional<U>
那么，我们的flatMap也应该是这个样子！
struct Async<T>{
let asyncFunction:(T->Void)->Void
func flatMap<U>(transform: T->Async<U>)->Async<U>{
//fill this function
}}
剩下的事情，就只是将这个函数体按照前面整理出的“然后根据上一步的数据,在transform中计算出新的Async，进行补玩就OK了。
具体补完的代码我就不在这里写出来了，如果实在还写不出，可以去参考傅若愚GitHub上面找一个Demo，但我更建议你尝试着自己将它补完。
------最后，谁提Monad我跟谁急！------ 这个是@傅若愚说的，monad只是一个概念而已，他的意思应该是指，我们不要丢下更加重要的抽象计算过程不顾，而去追逐一个对函数式编程思想不太重要的概念。
