> 文档中心 > 火车残骸和基本类型偏执问题解决方案

火车残骸和基本类型偏执问题解决方案

坏味道:缺乏封装。封装,将碎片式代码封装成可复用模块。但不同级别程序员对封装理解程度差异大,往往写代码的人认为自己提供了封装,但实际上,我们还是看到许多的代码散落在那里。

1 火车残骸

获得一篇博客作者名字:

String name = article.getAuthor().getName();

博客里有作者信息,想要获得作者名,通过“作者”找到“作者姓名”,这就是很多人凭借直觉写出的代码,这有问题!

是不是感觉自己无法理解封装了?

若你想写出上面这段,是不是得先了解Article、Author两个类的实现细节?即我们得知道,作者的姓名存储在作品的作者字段

这就是问题:当你须先了解一个类的细节,才能写代码,这只能说明这封装不优雅。

翻翻你手头的项目,这种在一行代码中有连续多个方法调用的情况是不是随处可见?

Martin Fowler 在《重构》中给这种坏味道起的名字叫过长的消息链(Message
Chains),而有人则给它起了一个更为夸张的名字:火车残骸(Train Wreck),形容这样的代码像火车残骸一般,断得一节一节。

解决这种代码的重构方案叫隐藏委托关系(Hide Delegate),即把这种调用封装:

class Book {  ...  public String getAuthorName() {    return this.author.getName();  }  ...}String name = book.getAuthorName();

2 产因

对封装理解不够,大部分人对封装仅停留在:数据结构+算法。
学习数据结构时,写代码都是拿到各种细节直接操作,但那是在做练习,不是工程。有人编写一个新类:

  • 第一步是写出这类要用的字段
  • 然后给这些字段生成各种 getXXX

很多语言或框架提供的约定就是基于这种 getter的,就像 Java 里的 JavaBean,相应配套工具lombok也很方便。让暴露越来越容易,封装反而无人在意了。

但要想成为架构师,就从少暴露细节开始。声明完一个类的字段后,请停下生成 getter 的手,思考类应该提供的行为。

3 迪米特法则

  • 每个单元对其它单元只拥有有限知识,而且这些单元是与当前单元有紧密联系
  • 每个单元只能与其朋友交谈,不与陌生人交谈
  • 只与自己最直接的朋友交谈

该原则需要思考:哪些是直接朋友、陌生人。
火车残骸代码就是没考虑这些问题,直接闷头写代码。写时一时爽,重构火葬场。

按迪米特法写代码,会不会让代码里有太多简单封装的方法?

有可能,不过,这也是单独解决这一个坏味道可能带来的结果。这种代码本质是缺乏对封装的理解,而一个好的封装需要基于行为。所以,把视角再提升,应考虑类应该提供哪些行为,而非简单地把数据换一种形式呈现就止步了。

有些内部 DSL 的表现形式也是连续的方法调用,但 DSL 是声明性的,在说做什么(What),而这里的坏味道是在说怎么做(How),二者抽象级别不同,不要混谈。

4 基本类型偏执

public double getEpubPrice(final boolean highQuality,   final int chapterSequence) {  ...}

根据章节信息获取 EPUB 价格。问题在返回值类型,即价格类型。在DB存储价格时,就是用一个浮点数,用 double 可保证计算的精度,这设计有问题?确实,这就是很多人使用基本类型(Primitive)作为变量类型思考的角度。但这种采用基本类型设计缺少一个模型

虽价格本身用浮点数存储,但价格和浮点数本身不是同一概念,有着不同行为需求。一般要求商品价格大于 0,但 double 类型本身没这限制。

以“价格大于0”这个需求为例,使用 double 类型怎么限制?

if (price <= 0) {  throw new IllegalArgumentException("Price should be positive");}

如果使用 double 作为类型,那我们要在使用的地方都保证价格的正确性,像这样的价格校验就应该是使用的地方到处写。若补齐这缺失的模型,可引入一个 Price 类型,校验就可放在初始化时:

class Price {  private long price;    public Price(final double price) {    if (price <= 0) {      throw new IllegalArgumentException("Price should be positive");    } this.price = price;  }}

引入一个模型封装基本类型的重构手法,叫以对象取代基本类型(Replace Primitive with Object)。有这模型,还可再进一步,如若让价格在对外呈现时只有两位,在没有 Price 类时,这样逻辑散落各处,代码里很多重复逻辑就是这样产生的。

可在 Price 类里提供一个方法:

public double getDisplayPrice() {  BigDecimal decimal = new BigDecimal(this.price)return decimal.setScale(2, BigDecimal.ROUND_HALF_UP).doubleValue();}

使用基本类型和使用继承出现的问题异曲同工。大部分程序员都了解组合优于继承,即不要写出这样的代码:

public Books extends List<Book> {  ...}

而应该写成组合:

public Books  {  private List<Book> books;  ...}
  • 把Books写成继承,是因为在开发者眼里,Books 就是一个书的集合
  • 有人用 double 做价格的类型,因为在他看来,价格就是一个 double

误区在于,一些程序员只看到模型相同之处,却忽略差异。Books 可能不需要提供 List 的所有方法,价格的取值范围与 double 也有差异。

但 Books 问题相对容易规避,因为产生了一个新模型,有通用的设计原则帮助我们判断这个模型构建得是否恰当,而价格问题却不容易规避,因为这里没有产生新的模型,也就不容易发现问题。

这种以基本类型为模型的坏味道称为基本类型偏执(Primitive Obsession)。这基本类型,不限于程序设计语言提供的各种基本类型,像字符串也是。很多对集合类型(比如数组、List、Map 等等)的使用也属于这坏味道:

  • 封装所有的基本类型和字符串
  • 使用流的集合

封装之所以有难度,在于它是一个构建模型的过程,而很多程序员写程序,只是用粗粒度理解写着完成功能的代码,没有构建模型意识;还有一些人以为划分模块就叫封装,所以,才会看到这些坏味道。

所以,真正要写好代码,要对软件设计有深入学习。

5 总结

与封装有关的坏味道:

  • 过长的消息链,或者叫火车残骸
  • 基本类型偏执。

火车残骸的代码就是连续的函数调用,它反映的问题就是把实现细节暴露了出去,缺乏应有的封装。重构的手法是隐藏委托关系,实际就是做封装。软件行业有一个编程指导原则,叫迪米特法则,可以作为日常工作的指导,规避这种坏味道的出现。

基本类型偏执就是用各种基本类型作为模型到处传递,这种情况下通常是缺少了一个模型。解决它,常用的重构手法是以对象取代基本类型,也就是提供一个模型代替原来的基本类型。基本类型偏执不局限于程序设计语言提供的基本类型,字符串也是这种坏味道产生的重要原因,再延伸一点,集合类型也是。

这两种与封装有关的坏味道,背后体现的是对构建模型了解不足,其实,也是很多程序员在软件设计上的欠缺。想成为一个更好的程序员,学习软件设计是不可或缺的。

构建模型,封装散落的代码。

6 怎样的封装算高内聚?

链式调用不一定都是火车残骸,比如:

  • builder模式,每次调用返回的都是自身,不牵涉到其他对象,不违反迪米特法则
  • java stream操作,就是声明性操作。

构建模型还有一个好处是加了一层抽象,屏蔽了外部变化,类似防腐层。
比如DDD中领域内只处理本领域的对象,使用其他领域的对象要先经过转换而非直接使用。

JavaBean,用MyBatis Genarater或Lombok生成都会有Setter方法,这样DB查询或接受参数时,数据自动映射到这个对象。如果不用setter,怎么赋值?
现在的数据库映射用的都是反射实现,与setter关系不大。

  1. 若你的编码方式是置顶向下的,且当前层都只面向意图定义空类和空函数。写出提倡的这种风格其实很正常。
  2. 结合1描述的编码方式。顶层类中不会有基础类型,每个属性的类型都会是一个面向意图的类来承接。顶层函数的实现部分只会有一个个函数,哪怕函数实现只有一行。