常见的代码”坏味道”

正所谓优雅的代码是相似的, 不优雅的代码却各有各的丑. 最近在拜读<重构- 改善既有代码的设计>一书, 虽然书中大量示例是用Java编写的, 但是也给了我很多启发.
见贤思齐, 耗时把感想记录下来, 督促自己的成长.

重复代码

坏味道行列中 ,最常见的就是Duplicated Code. 如果你在一个以上的地点看到相同的程序结构, 那么可以肯定: 把他们合而为一, 会使得代码变得更好.

1. 最单纯的Duplicated Code就是”同一个类的两个函数有相同的表达式”, 解决办法就是:

   • 采用Extract Method(提炼函数)提炼出重复的代码, 然后这两个地方都调用提炼出来的那一段代码.

2. 两个互为兄弟的子类内包含相同的表达式, 解决办法就是:

   • 对两个类都是用Extract Method(提炼函数), 再对提炼出来的代码使用Pull Up Method(函数上移)
   • 如果代码只是类似而不完全相同, 那就要先使用Extract Method(提炼函数)将相似和差异的代码分隔开, 构造成一个单独的函数, 然后再塑造模板函数

3. 如果两个毫不相关的类出现Duplicated Code, 应该把重复代码提炼到一个独立类中, 然后再另一个类中使用这个新类

函数上移(Pull Up Method): 若干个身处子类中的函数, 他们又可以通过某种形式的参数调整成为相同的函数. 这时候, 最简单的方法就是首先分别调整这些函数的参数, 然后再将他们概括到父类中去. 特殊情况: 当子类的函数覆写了父类的函数, 但却仍然做相同的工作.

塑造模板函数(Form Template Method): 两个函数以相同顺序执行大致相近的操作, 但是各操作不完全相同. 这种情况下我们可以将执行操作的序列移至父类, 并借助多态保证各操仍得以保持差异性.

过长函数(Long Method)

程序愈长愈难理解.
我们应该积极地分解函数, 只要你感觉需要在一个地方加注释, 我们就要把需要说明的东西写进一个独立函数, 并以其用途(而非实现手法)命名. 哪怕替换后的函数调用动作比函数自身还长, 只要函数名称能够解释其用途, 我们就应该毫不犹豫地那么做, 关键不在于函数的长度, 而在于”做什么”和”如何做”之间的语义距离.

1. 大多数场合, 把函数变小, 只需使用Extract Method(提炼函数). 找到函数中适合集中在一起的部分, 将他们提炼出来一个新函数.
2. 如果函数中有大量的参数和临时变量, 他们会对你的函数提炼形成阻碍. 如果

过大的类(Large Class)

过长参数列(Long Parameter List)

发散式变化(Divergent Change)

霰弹式修改(Shotgun Surgery)

依恋情结(Feature Envy)

数据泥团(Data Clumps)

基本类型偏执(Primitive Obsession)

Switch 惊悚现身(Switch Statements)

平行继承体系(Parallel Inheritance Hierarchies)

冗赘类(Lazy Class)

夸夸其谈未来性(Speculative Generatlity)

令人迷惑的暂时字段(Temporary Field)

过度耦合的消息链(Message Chains)

中间人(Middle Man)

狎昵关系(Inappropriate Intimacy)

异曲同工的类(AlertNative Classes with Different Interfaces)

不完美的库类(Incomplete Library Class)

纯稚的数据类(Data Class)

被拒绝的遗赠(Refused Bequest)

过多的注释(COmments)