函数式非凡的抽象能力

我在阅读或编写具备函数式风格的代码时，经常为函数式思想非凡的抽象能力所惊叹。做为一直以来持有OO信仰的程序员而言，对于“抽象”并不陌生。我甚至将面向对象思想的精髓定义为两个单词：职责（Responsibility）与抽象（Abstraction）。只要职责分配合理，设计就是良好的；若能再加上合理的抽象，程序会变得更精简且可扩展。若是你熟悉GoF的设计模式，你几乎能够从每一个模式中读出“抽象”的意义来。

然而，不管如何，面向对象思想构筑的实际上是一个名词的世界，这在很大程度上局限了它的世界观，它只能以实体（Entity）为核心。虽然咱们仍然能够针对实体提炼共同特征，但这些特征若为行为，却没法单独存在，这是面向对象思想的硬伤。

若是说面向对象思想是物质世界的哲学观，则函数式思想展示的就是纯粹的数学思惟了。函数做为一等公民，它不表明任何物质（对象），而仅仅表明一种转换行为。是的，任何一个函数均可以视为一种“转换(transform)”。这是对行为的最高抽象，表明了类型（type）[注意，是类型（type），而不是类（class）]之间的某种动做。函数能够是极为原子的操做，也能够是多个原子函数的组合，或者在组合之上再封装一层语义更清晰的函数表现。

理解了函数的转换本质，咱们就必须学会在具体行为中“洞见”这种转换本质。这种“洞见”能够理解为解构分析，就好似咱们在甄别化石的年代时，利用核分析技术去计算碳14同位素原子数量通常。咱们解构出来的“原子”函数每每具备非凡的抽象能力。例如，咱们针对集合的sum与product操做，能够解构出原子的fold函数。虽然从行为特征看，sum为求和，product为求积，但从抽象层面看，都是从一个初始值开始，依次对集合元素进行运算。而运算自己，又是抽象的另外一个转换操做，从而引入了高阶函数的概念。若要让fold不止局限于某一种具体类型，则能够引入函数式语言的类型系统。fold能够根据折叠的方向分为foldRight与foldLeft。foldRight（或flodr）的函数定义以下：

//scala语言
def fold[A, B](l: MyList[A], z: B)(f: (A, B) => B):B = l match {
    case Nil => z
    case Cons(x, xs) => f(x, fold(xs, z)(f))
}复制代码

--haskell语言
foldr f zero (x:xs) = f x (foldr f zero xs)
foldr _ zero []     = zero复制代码

《深刻理解Scala》一书在讲解Scala的Option时，给出了一个有趣的案例，其中揭示的抽象思想与fold有殊途同归之妙。这个案例讲解了如何用多个可能未初始化的变量构造另外一个变量，Option正适合处理这种状况，我在博客《并不是Null Object这么简单》中介绍了Option的本质，这里再也不赘述。这个例子是但愿经过数据库配置信息建立链接。因为配置信息可能有误，建立的链接可能为null，于是使用Option的api会更加健壮：

def createConnection(conn_url: Option[String],
                     conn_user: Option[String],
                     conn_pw: Option[String]): Option[Connection] = 
    for {
        url <- conn_url
        user <- conn_user
        pw <- conn_pw
    } yield DriverManager.getConnection(url, user, pw)复制代码

如今，咱们将这个函数无限抽象化，那就是要去掉一些复杂而冗余的具象信息，就好像过滤掉让人眼花缭乱的缤纷颜色，仅仅呈现最朴素的黑白二色通常。首先，咱们抹掉“建立链接”的特征，而后再抹掉类型信息。咱们能够看到createConnection实则是对DriverManager.getConnection的转换，经此转换后，若要建立链接，就能够传入三个Option[String]类型的参数，得到Option[Connection]类型的结果。而后再去掉具体的String类型，就能够抽象出以下的“转换”操做：

(A, B, C): => D     转换为      (Option[A], Option[B], Option[C]) => Option[D]复制代码

注意，这个转换操做是函数到函数的转换。

书中找到了一个正确的概念来恰如其分地描述这一“转换”操做，即为lift（提高）：

def lift[A, B, C, D](f: Function3[A, B, C, D]): Function3[Option[A], Option[B], Option[C], Option[D]] = 
    (oa: Option[A], ob: Option[B], oc: Option[C]) => 
        for (a <- oa; b <- ob; c <- oc) yield f(a, b, c)复制代码

Function3事实上是Scala中对(A, B, C) => D函数的封装。相对而言，我更喜欢高阶函数的形式：

def lift[A, B, C, D](f: (A, B, C) => D): (Option[A], Option[B], Option[C]) => Option[D] =
    (oa: Option[A], ob: Option[B], oc: Option[C]) => 
        for (a <- oa; b <- ob; c <- oc) yield f(a, b, c)复制代码

lift函数是宽泛的抽象，以前的DriverManager.getConnection()函数则为一个具体的被转换对象。它能够做为参数传入到lift函数中：

val createConnection1 = lift(DriverManager.getConnection)复制代码

lift函数返回的实则是一个函数，它本质上等同于以前定义的createConnection()函数。因为lift抹掉了具体的类型信息，使得它不只仅能够将getConnection提高为具备Option的函数，还能针对全部形如(A, B, C) => D格式的函数。让咱们来自定义一个combine函数：

def combine(prefix: String, number: Int, suffix: String): String =
    s"$prefix - $number - $suffix"

val optionCombine = lift(combine)复制代码

区分combine函数与opitonCombine函数的执行结果：

lift的执行结果

诸如fold或lift这样的终极抽象在函数式语言的api中可谓俯拾皆是，如针对集合的monad操做filter, flatMap, map，又例如函数组合的操做sequence，andThen等。咱们还能够结合转换语义为这种基本转换命名，使得代码更加简略可读。例如针对以下的三个函数定义：

def intDouble(rng: RNG): ((Int,Double), RNG)
def doubleInt(rng: RNG): ((Double,Int), RNG)
def double3(rng: RNG): ((Double,Double,Double), RNG)复制代码

咱们能够抽象出RNG => (A, RNG)的通用模式，而后从语义上将其命名为Rand，那么，在scala中能够利用type关键字为这种转换定义别名：

type Rand[+A] = RNG => (A, RNG)复制代码

当咱们将函数做为基本的抽象单元后，再对面向对象思想作一次回眸，会发现OO中的多数设计原则与设计模式，均可以简化为函数。Scott Wlaschin在Functional Design Patterns的演讲中给出了很是形象的对比：

OO与FP的设计原则

显然，函数才是最为纯粹的抽象。正所谓“大道至简”，有时候，简单可能就意味着一切。