我们会频繁地使用Scala的Option，用以解决类似Null Object之类的问题。某种程度讲，使用Option必然会减少对空指针引用判断的丑陋代码，结合For Comprehension，确乎是Scala编程中的一把利器。我在博客《引入Option优雅地保证健壮性》与《并非Null Object这么简单》中都详细对Option的本质与运用进行剖析与介绍。
然而，Option虽然好，我们却不可“贪杯”哦！
从语义上讲，Option代表一种容器（Monad）非空即有的两种状态，例如List的headOption就是对Option的合理诠释。那么，是否只要是两种状态的业务场景，就可以使用Option呢？例如，将函数的参数类型定义为Option类型，用以表示用户传参的选择：传入实际值或者不传值。这是否是得体的姿势？
Daniel Westheide发表的博文When Option Is Not Good Enough旗帜鲜明地表达了反对意见。他给出这样的一个案例：根据产品标题与零售商信息查询Offer：
def searchOffers( productTitle: Option[String], retailer: Option[Retailer] ): Seq[Offer] = ???
作为这个函数的调用者，我们该怎么看待这两个Option参数传递的业务含义？如果productTitle为None，是表示忽略productTitle的值，仅仅搜索符合retailer条件的offers；还是搜索没有提供productTitle的Offer记录？同样，retailer参数也传递了如此模糊不清的意图！
好的代码尤其是接口应该是”不言自明“清晰地传递开发者意图。落到具体的业务场景，则代码就应该恰到好处干净利落地表现其业务含义。接口体现准确的业务通用语言（ubiquitous language），是DDD的核心价值。
如果我们为这两个搜索条件定义表达业务含义的代数数据类型（algebraic data types），如下代码所示，表意无疑要清晰许多：
sealed trait SearchCriteriaobject SearchCriteria { final case object MatchAll extends SearchCriteria final case class Contains(s: String) extends SearchCriteria } sealed trait RetailerCriteriaobject RetailerCriteria { final case object AnyRetailer extends RetailerCriteria final case class Only(retailer: Retailer) extends RetailerCriteria } def searchOffers( product: SearchCriteria, retailer: RetailerCriteria ): Seq[Offer] = ???
SearchCriteria与RetailerCriteria作为两个查询条件，分别提供了各自的查询语义，显然要比过分抽象的Some与None更加清晰可读。
引入这样的代数数据类型不仅可以让代码的表意更清晰，还可更好地应对需求的变化。对于现有的SearchCriteria定义而言，倘若要牵强附会，确实可以强词夺理地说：MatchAll就是None的语义，而Contains则对应着Some。然而，如果需求要求增加完全匹配的查询场景，对于Option类型而言，该如何表达？回到SearchCriteria的定义，我们可以轻松地为其增加一种类型：
object SearchCriteria { final case object MatchAll extends SearchCriteria final case class Contains(s: String) extends SearchCriteria final case class Exactly(s: String) extends SearchCriteria
}
比较Option而言，增加了一种新的类型，却极大地提高了代码的可读性，也为代码的未来扩展奠定了基础。与获得的收益相比，仅仅是付出新增类型的微末代价，何足道哉！
