前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >深入探索Scala的Option

深入探索Scala的Option

作者头像
张逸
发布2018-03-07 16:36:39
1.1K0
发布2018-03-07 16:36:39
举报
文章被收录于专栏:斑斓

程序员最深恶痛绝并力求避免的异常是NullPointerException,很不幸,我们往往又会忽略这个错误。不知是谁设计了Null这样的对象。我在文章《并非Null Object这么简单》中已经阐释了这个问题。然而不仅仅是空指针异常,当程序代码中出现各种错误时,我们的处理方式该如何呢?

现在,让我们再看看Scala语法层面的Option。Option对象并没有从根本上解决程序错误的问题,但只要使用得当,就能有效地将错误往程序的外层推,这实际上是消除副作用的惯常做法。正如Paul Chiusano等人的著作《Scala函数式编程》描述的那样:

对函数式程序员而言,程序的实现,应该有一个纯的内核和一层很薄的外围来处理副作用。

REA的Scala程序员Ken Scambler在YOW!大会上有一个很棒的演讲2 Year of Real World FP at REA。演讲中提到REA选择函数式编程的三个原因:

  • 模块化(Modularity)
  • 抽象(Abstraction)
  • 可组合性(Composability)

模块化的一个重要特征是设计没有副作用的纯函数,这样就不会影响调用该纯函数的上下文,也就是所谓的“引用透明(Reference Transparency)”概念,即针对任何函数都可以使用它的返回值来代替(substitution)。

Ken Scambler使用了一个解析字符串的例子来阐释这种纯函数特质。如下代码所示:

代码语言:javascript
复制
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可能导致类型转换异常

仅仅从函数的定义来看,我们其实看不到这些潜在的负面影响。那么,想像一下当这样的方法被系统中许多地方直接或间接调用,可能会造成什么样的灾难?!假设这样的代码被放到安全要求极高的系统中,你是否会感到不寒而栗?——程序员,应该在道义上肩负为自己所写每行代码承担自己的责任,这是基本的职业素养。我所谓的承担责任,并不是事后追究,而是在每次写完代码后都要再三推敲,力求每行代码都是干净利落,没有歧义,没有潜在的错误。

然而,针对以上代码,要怎样才能保证程序调用的健壮性呢?就是要对可能出现的错误(空对象,索引越界,类型转换异常)进行判断。这就需要在parseLocation函数体中加入一堆if语句,短短的六行代码可能会膨胀一倍,而分支语句也会让程序的逻辑变得凌乱,正常逻辑与异常逻辑可能会像麻花一样扭在一起。当然,我们可以运用防御式编程,将可能的错误防御在正常逻辑代码之前,但它带来的阅读体验却会非常糟糕。

即使针对这些错误进行判断,仍然无法解决的一个问题是当对象真的出现错误时,函数实现究竟该如何处理?多数语言不支持多返回值(乃至不支持类似Scala的Pair),经典的解决办法就是抛出异常,可惜,异常却存在副作用。许多程序员更习惯性的返回了null。这是最要命的做法,就好像是慕容复的“以彼之道,还施彼身”,典型地损人利己!

引入Option,会让代码在保证健壮性的同时还保证了简洁性,例如:

代码语言:javascript
复制
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)}

本质上,Option是一个Monad;简单来说,是一个定义了flatMap与map的容器,故而能够支持Scala中可读性更佳的for comprehension。如上代码简单明了,你甚至可以忽略当Option为None的情形,只考虑正常的字符串解析逻辑,它自然地隐含了None的语义,因为在代码中通过optGet与optToInt返回的值(为Option类型),只要其中一个为None,整个函数就将即刻返回一个None对象,而非一个包裹了Location的Some对象。这样既避免了使用分支语句,还能使得函数没有任何副作用,规避了抛出异常的逻辑。

如上的改进仍然存在一个问题,那就是缺乏对输入的str进行判断。一个好的API设计者或者函数实现者,要怀着“性本恶”的悲观主义道德观,对任何输入持怀疑态度,且不惮于怀疑调用者的恶意。对于输入的这个str,我们仍然要避免使用条件判断的方式,因而可以修改函数的接口为:

代码语言:javascript
复制
def parseLocation(str: Option[String]): Option[Location] = ???

如此,我们可以将对str的解析逻辑也挪动到for comprehension中:

代码语言:javascript
复制
def parseLocation(str: Option[String]): Option[Location] = {  
for {   
 val parts = str.split(",")    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)}

使用Option的唯一问题是:你虽然指定了Option这样的游戏规则,但其他API的设计者却未必按照你设计的规则出牌。这也是如上代码中optGet之类函数的由来。即使是Scala的内置库,如String的split函数,返回的也并非一个Option,而是一个普通的数组。当我们给一个错误的下标值去访问数组时,有可能会抛出ArrayIndexOutOfBoundsException异常。

Scala提供的解决方案是隐式转换(implicit conversion)。split()函数返回的类型为Array[String],该类型自身是没有optGet()函数的。但是我们可以为Array[String]定义隐式转换:

代码语言:javascript
复制
implicit class ArrayWrapper(array: Array[String]) {  
  def optGet(index:Int): Option[String] =     if (array.length > index) Some(array(index)) else None}

optToInt方法可以如法炮制。

惯常说来,当我们在使用Option时,习惯于利用模式匹配(pattern match)以运用“分而治之”的思想来编写代码。然而,多数时候我们应该使用定义在Option中的函数,这些函数可以让代码变得更简单。例如使用flatMap、map、isDefined、isEmpty、forAll、exists、orElse、getOrElse等函数。Tony Morris整理的scala.Option Cheat Sheet总结了这些函数的用法,可供参考。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2016-06-11,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 逸言 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
容器服务
腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档