引入Option优雅地保证健壮性

REA的Ken Scambler在其演讲《2 Year of Real World FP at REA》中,总结了选择函数式编程的三个原因:Modularity, Abstraction和Composability。

函数式编程强调纯函数(Pure Function),这是模块化的一个重要基础,因为对于纯函数而言,可以不用考虑调用的上下文,就可以根据函数的输入推断函数的执行结果。这也就是Ken所谓的:

You can tell what it does without Looking at surrounding context.

Ken在演讲中给出了一个案例:

def parseLocation(str: String): Location = {
  val parts = str.split(",")
  val secondStr = parts(1)
  val parts2 = secondStr.split(" ")
  Location(parts(0), parts2(0), parts(1).toInt)}

仔细阅读这段代码,你会发现这段代码是不健壮的,可能存在如下错误:

  • 作为input的str可能为null
  • parts(0)和parts(1)可能导致索引越界
  • parts2(0)可能导致索引越界
  • parts(1)未必是整数,调用toInt可能导致类型转换异常

这段代码隐含的错误还可能被广泛地蔓延到系统的其他地方,只要该函数被调用。这种蔓延可能会因为更多嵌套的调用而产生级联的错误效应。例如:

def doSomethingElse(): Unit = {
  // ...Do other stuff
  parseLocation("Melbourne, VIC 3000")}

doSomethingElse()函数又被其他函数调用,这些潜在的缺陷会分布到各个直接或间接的调用点。这意味着代码会继承它所调用代码的错误以及副作用,使得对代码功能的推理(reasoning)变得近乎不可能,更不用说代码的模块化(modularity)了。

我们当然可以通过对null进行检测来避免出现这些错误。然而看看各种出现null值的可能分支,需要我们做各种条件判断,想象这样的代码都让人不寒而栗。引入Option类型就可以很好地封装这种可能性。按照Ken的说法就是:

All possibilities have been elevated into the type system.

def parseLocation(str: String): Option[Location] = {
 val parts = str.split(",")
 for {
   locality <- parts.optGet(0)
   theRestStr <- parts.optGet(1)
   theRest = theRestStr.split(" ")
   subdivision <- theRest.optGet(0)
   postcodeStr <- theRest.optGet(1)
   postcode <- postcodeStr.optToInt
 } yield Location(locality, subdivision, postcode)}

以上代码中,split()函数返回的类型为Array[String],该类型自身是没有optGet()函数的。但是我们可以为Array[String]定义隐式转换:

implicit class StringArrayWrapper(array: Array[String]) {
    def optGet(index:Int): Option[String] = {
        if (array.length > index) Some(array(index)) else None
    }}

optToInt方法可以如法炮制。

Ken的解决方案并没有考虑到parseLocation函数入参str存在null值的可能,故而在对str调用split方法时仍然有可能导致抛出空指针异常。因此进一步,我们还可以修改parseLocation函数的定义:

def parseLocation(optStr: Option[String]): Option[Location]

显然,通过引入Option,既规避了前面分析可能出现的错误,又能避免编写繁琐的if判断。这里的关键点是Option对两种可能性(None与Some)的封装。它由两个代数类型Some与None构成,前者包含了一个值,而后者则包含了一个不存在的值。事实上,Option是一个Maybe Monad,实现了flatMap与filter,因而在Scala中可以用for comprehension来访问。

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

原文发表时间:2017-01-19

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏深度学习那些事儿

探讨pytorch中nn.Module与nn.autograd.Function的backward()函数

本文讲解基于pytorch0.4.0版本,如不清楚版本信息请看这里。backward()在pytorch中是一个经常出现的函数,我们一般会在更新loss的时候使...

3664
来自专栏数据结构与算法

BZOJ4916: 神犇和蒟蒻(杜教筛)

$$g(1)s(n) = \sum_{i = 1}^n g(i)s(\frac{n}{i}) - \sum_{i = 2}^n g(i)s(\frac{n}{i...

842
来自专栏小詹同学

Leetcode打卡 | No.18 四数之和

欢迎和小詹一起定期刷leetcode,每周一和周五更新一题,每一题都吃透,欢迎一题多解,寻找最优解!这个记录帖哪怕只有一个读者,小詹也会坚持刷下去的!

712
来自专栏Danny的专栏

探秘VB.net中的shared与static

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/huyuyang6688/article/...

641
来自专栏Fundebug

你试过不用if撸代码吗?

译者按: 试着不用if撸代码,是件很有趣的事,而且,万一你领会了什么是“数据即代码,代码即数据”呢?

1024
来自专栏数据结构与算法

20:反反复复

20:反反复复 总时间限制: 1000ms 内存限制: 65536kB描述 Mo和Larry发明了一种信息加密方法。他们首先决定好列数,然后将信息(只包含字...

3398
来自专栏程序员互动联盟

在编程中写的最多的一句代码是啥?

挺有意思的一个问题,作为一个天天写代码的人平时也没怎么太在意这些细节,过滤了几种编程语言,大致总结了几种常用的代码

853
来自专栏撸码那些事

【抽象那些事】不必要的抽象

抽象实体应该具有单一而重要的职责。如果创建的没必要或是只是为了方便,它们承担的职责微不足道,甚至没有承担任何职责,这违反了抽象原则。

1107
来自专栏java一日一条

Java函数式开发——优雅的Optional空指针处理

空闲时会抽空学习同在jvm上运行的Groovy和Scala,发现他们对null的处理比早期版本Java慎重很多。在Java8中,Optional为函数式编程的n...

361
来自专栏python3

python 购物车程序

672

扫描关注云+社区