MENU

《重构》第三章学习笔记

January 16, 2020 • 《重构-改善既有代码的设计》读书笔记

前面两张学习了如何进行重构,那么选择什么情况下进行重构呢?

本章介绍了22种应该需要进行重构的情况。

  • 重复代码

合并相同的程序结构,如果并非完全相同,就要将相同的和差异的部分分隔开。

  • 过长函数

程序越长越难理解,将长函数分割为小函数,并且要取一个能让开发者一眼就能看出其中功能的函数名。

  • 过大的类

根据功能提炼类的接口能够更清楚的分解类。

  • 过长参数列

太多的参数列难以让开发者理解,太多的参数会造成前后不一致,不宜使用。

  • 发散式变化

针对外界所有相应修改,都只应该发生在单一类中,而这个新类内所有内容都应该反映次变化。找出特定原因而造成的所有变化,然后将他们提炼到另一个类中。

  • 霰弹式修改

一种变化引发多个类相应修改,把一系列相关行为放进同一个类,虽然会造成少量的Divergent Change(一个类受多种变化的影响),但是可以轻易的处理它们。

  • 依恋情节

依恋情节是函数对某个类的兴趣高过对自己类的兴趣,判断哪个类拥有最多被此函数使用的数据,然后就把这个函数和那些数据放在一起。

  • 数据泥团

创造新类时寻找有依恋情节的方法。

  • 基本类型偏执

对常常放在一起的基本类型参数进行封装。

  • Switch惊悚现身

switch造成重复的问题,将其提炼到单独的方法中。

  • 平行继承体系

让一个继承体系的实例引用另一个继承体系的实例。

  • 冗赘类

对于几乎没用的组件应该删除。

  • 夸夸其谈未来性

如果某个抽象类其实没有太大的作用,当前不值得维护,将其删除。

  • 令人迷惑的暂时字段

对于使用某个算法时使用的临时变量,将其都放在字段中。

  • 过度耦合的消息链

大量参数的传递会造成过度耦合,可以将其封装进对象中。

  • 中间人

作用不大的中间函数可以删除

  • 狎昵关系

如果子类的功能超出了父类的范围,应将其单独出来。

  • 异曲同工的类

虽然操作不同的对象但做同一件事的,可以将其稍作修改使其合并。

  • 不完美的类库

如果类库不够好,可以尝试修改类库中的函数。

  • 纯稚的数据类

在数据类中使用Getter,Setter。

  • 被拒绝的遗赠

子类复用父类的实现时,一定要继承父类的接口。

  • 过多的注释

重构结束后删除多余的注释。

Last Modified: January 22, 2020
Archives QR Code Tip
QR Code for this page
Tipping QR Code