函数式非凡的抽象能力

如果说面向对象思想是物质世界的哲学观,则函数式思想展现的就是纯粹的数学思维了。函数作为一等公民,它不代表任何物质(对象),而仅仅代表一种转换行为。是的,任何一个函数都可以视为一种“转换(transform)”。这是对行为的最高抽象,代表了类型(type)之间的某种动作。函数可以是极为原子的操作,也可以是多个原子函数的组合,或者在组合之上再封装一层语义更清晰的函数表现。

△ 插图 | 欧洲系列 - 斯特拉斯堡,法国

我在阅读或编写具有函数式风格的代码时,常常为函数式思想非凡的抽象能力所惊叹。作为一直以来持有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的模式与原则

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2015-02-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏轮子工厂

设计模式(一) | 啥是工厂模式和策略模式?

552
来自专栏cloudskyme

设计模式(6)-装饰器(认识程序中的装饰器)

之前已经看过装饰器模式,但是感觉不是很清晰,但是有一种情况下出的代码,一定是装饰器。 Widget* aWidget = new BorderDecorator...

3137
来自专栏Albert陈凯

Scala代码编写中常见的十大陷阱

很多Java开发者在学习Scala语言的时候,往往觉得Scala的语法和用法有些过于复杂,充满语法糖,太“甜”了。在使用Scala编写代码时,由于语法和编写习惯...

2315
来自专栏木宛城主

Unity应用架构设计(5)——ViewModel之间如何共享数据

对于客户端应用程序而言,单页应用程序(Single Page Application)是最常见的表现形式。有经验的开发人员往往会把一个View分解多个SubV...

1816
来自专栏GopherCoder

『Go 语言学习专栏』-- 第八期

1755
来自专栏大闲人柴毛毛

柴毛毛大话设计模式——开发常用的设计模式梳理

写在最前 本文是笔者的一点经验总结,主要介绍几种在Web开发中使用频率较高的设计模式。 本文篇幅较长,建议各位同学挑选感兴趣的设计模式阅读。 在阅读的同时,也...

4247
来自专栏斑斓

编程实践 | Scala亮瞎Java的眼(一)

这是我在11月15日成都OpenParty分享的一个题目,确有标题党的嫌疑。Scala自然不是无所不能,Java也没有这么差劲,我只希望给Java程序员提供另外...

3175
来自专栏令仔很忙

新手学HighCharts(二)----对比柱状图的动态加载

上一篇文章 新手学HighCharts(一)—-基本使用 中介绍了highCharts的基本使用,今天给大家介绍对比柱状图的使用,贴张图先:

561
来自专栏光变

你所不知道的Java之Switch

??? Enum,String,Character,Byte,Short,Integer

1100
来自专栏斑斓

编程修炼 | Scala亮瞎Java的眼(二)

继续上一期的话题,介绍Scala有别于Java的特性。说些题外话,当我推荐Scala时,提出质疑最多的往往不是Java程序员,而是负责团队的管理者,尤其是略懂技...

3215

扫描关注云+社区