美文网首页
代码坏味道:可变的数据

代码坏味道:可变的数据

作者: GuangHui | 来源:发表于2022-09-26 09:10 被阅读0次

    呈现形态:

    • (1)缺失行为,暴露细节

    可变数据最直白的体现就是各种 setter。存在的问题:setter 一方面破坏了封装,同时把一个类的内部行为,即实现细节暴露了出来;另一方面它会带来不可控的修改,给代码增添许多问题。

    解决方式:引入行为,封装细节,对应有一种重构手法叫移除设值函数(Remove Setting Method),将变化限制在一定的范围之内。

    • (2)可变的数据

    可变数据是《重构》第二版新增的坏味道,它背后的思想是函数式编程所体现的不变性。

    解决可变数据,一种方式是限制其变化,另一种方式是编写不变类。

    • (3)全局数据

    编程规则:

    限制变化,尽可能编写不可变类。

    在实践中,完全消除可变数据是很有挑战的。所以,一个实际的做法是,区分类的性质。值对象就要设计成不变类,实体类则要限制数据变化。

    坏味道示例:

    满天飞的setter
    public void approve(final long bookId) {
        ...
        book.setReviewStatus(ReviewStatus.APPROVED);
        ...
    }
    

    上面这种操作,意味着你不仅可以读到一个对象的数据,而且还可以修改。而相比于读数据,修改是一个更危险的操作。可修改就意味着可变,而可变的数据会带来许多问题,简言之,你不知道数据会在哪里被何人以什么方式修改,造成的结果是,别人的修改会让你的代码崩溃。

    可变的数据是可怕,但是,比可变的数据更可怕的是,不可控的变化,而暴露 setter 就是这种不可控的变化。把各种实现细节完全交给对这个类不了解的使用者去修改,没有人会知道他会怎么改,所以,这种修改完全是不可控的。

    缺乏封装再加上不可控的变化,在我个人心目中,setter 几乎是排名第一的坏味道。

    上述代码优化重构之后:

    public void approve(final long bookId) {
        ...
        book.approve();
        ...
    
    }
    
    class Book {
        public void approve() {
            this.reviewStatus = ReviewStatus.APPROVED;
        }
    }
    

    将行为进行封装之后,作为类的使用者,并不需要知道这个类到底是怎么实现的。更重要的是,这里的变化变得可控了。虽然审核状态这个字段还是会修改,但你所有的修改都要通过几个函数作为入口。有任何业务上的调整,都会发生在类的内部,只要保证接口行为不变,就不会影响到其它的代码。

    初始化时后的setter
    Book book = new Book();
    book.setBookId(bookId);
    book.setTitle(title);
    book.setIntroduction(introduction);
    

    实际上,对于这种只在初始化中使用的代码,压根没有必要以 setter 的形式存在,真正需要的是一个有参数的构造函数。当构造方法的参数过多时,可考虑使用builder模式来重构。

    Book book = new Book(bookId, title, introduction);
    

    下面是 lombok.config 的配置,通过它,我们就可以禁用 @Setter 了:

    lombok.setter.flagUsage = error
    lombok.data.flagUsage = error
    

    你或许注意到了,这里除了 @Setter,我还禁用了 @Data,这是 Lombok 中另外一个 Annotation,表示的是同时生成 getter 和 setter。既然我们禁用 @Setter 是为了防止生成 setter,当然也要禁用 @Data 了。

    我们反对使用 setter,一个重要的原因就是它暴露了数据,我们前面说过,暴露数据造成的问题就在于数据的修改,进而导致出现难以预料的 Bug。在上面的代码中,我们把 setter 封装成一个个的函数,实际上是把不可控的修改限制在一个有限的范围内。

    那么,这个思路再进一步的话,如果我们的数据压根不让修改,犯下各种低级错误的机会就进一步降低了。这种想法源自函数式编程这种编程范式。在函数式编程中,数据是建立在不改变的基础上的,如果需要更新,就产生一份新的数据副本,而旧有的数据保持不变。

    在实际工作中,我们怎么设计不变类呢?要做到以下三点:

    • 所有的字段只在构造函数中初始化;

    • 所有的方法都是纯函数;

    • 如果需要有改变,返回一个新的对象,而不是修改已有字段。

    针对代码生成工具,如果它生成的是一个算法,比如编译器生成器,我可以去用,因为我只要关注接口,不需要关注细节。如果生成的是模型,我倾向于不用它,因为我要关注其中的细节。如果封装它,可能就失去了代码生成的意义。

    我常常说到软件设计的品位,生成大量 setter 代码的工具,本身就是设计品位不佳的体现。基于一个品位不佳的工具谈改进,这可能不是我关注的方向。

    相关文章

      网友评论

          本文标题:代码坏味道:可变的数据

          本文链接:https://www.haomeiwen.com/subject/ajmtartx.html