代码异味 (Code smells)
如果一段代码是不稳定或者有一些潜在问题的，那么代码往往会包含一些明显的痕迹。
正如食物要腐坏之前，经常会发出一些异味一样。
我们管这些痕迹叫做 代码异味 。
No.1 重复代码 (Duplicated Code)
解决方案:
-
同一个
class内的两个函数含有相同的表达式。——需要Extract Method，提炼出重复代码，然后让两个地点都调用被提炼出来的那一段代码。 -
两个互为兄弟的
subclass内含相同的表达式，要避免这种情况——需要两个class都使用Extract Method，把Extract的Method推入superclass内。 -
两个毫不相干的
classes内出现Duplicate Code，你应该考虑对其中一个使用Extract Class，将重复代码提炼到一个独立class中，然后在另一个class内使用这个新class。
No.2 过长方法 (Long Method)
所谓 “ 好处 ”
-
避免额外开销
-
不需要跳转上下文就能理解程序
解决方案:
-
注释
-
条件式
-
循环
No.3 过大类 (Large Class)
解决方案:
-
变量 & 方法
-
重新抽象
No.4 过长参数列表 (Long Parameter List)
会导致哪些问题
-
无用／开关／分类参数
-
难以理解
-
前后不一致，不易使用
-
经常需要修改
解决方案:
- 抽象成类
No.5 发散式变化 (Divergent Change)
表现：一个类受到多种变化的影响
解决方案:
- 重构，保持类功能单一
No.6 散弹式修改 (Shotgun Surgery)
表现：一种变化引发多个类相应修改
解决方案:
- 提取变化部分为公共的类
No.7 依恋情节 (Feature Envy)
表现：使用了大量其他类的成员
解决方案:
- 需要在一起的，就让他们在一起
No.8 数据泥团 (Data Clumps)
表现：常一起出现的一堆数据
解决方案:
- 那么有基情，就在一起吧，给他们一个新的类。
No.9 基本类型偏执 (Primitive Obsession)
解决方案:
-
反复出现的一组参数，抽象成类
-
有关联的多个数组，抽象成类
No.10 switch惊悚现身 (Switch Statements)
解决方案:
-
state/strategy/多态
No.11 平等继承体系 (Parallel Inheritance Hierarchies)
表现：每当你为某个
class增加一个subclass，必须也为另一个class相应增加一个subclass。
解决方案:
- 应该有一个类是可以去掉继承关系
No.12 冗余类 (Lazy Class）
解决方案:
- 删除
No.13 夸夸其谈未来 (Speculative Generality)
解决方案:
- 删除
No.14 临时字段 (Temporary Field)
解决方案:
- 抽象成类
No.15 过度耦合的消息链 (Message Chains)
表现：用户向一个对象索求另一个对象，然后再向后者索求另一个对象，然后再索求另一个对象……这就是
Message Chain
解决方案:
- 拆
No.16 中间转手人 (Middle Man)
表现：某个类接口有一半的方法都委托给其它类
实质：委托的过度使用
解决方案:
- 继承代替委托
No.17 太亲密 (Inappropriate Intimacy)
表现：两个类彼此使用对方私有的成员或方法
解决方案:
- 划清界限拆散／合并／单向联系
No.18 不同接口的相似类 (Alternative Classes with Different Interfaces)
解决方案:
- 合并
No.19 不完善的类库 (Incomplete Library Class)
解决方案:
- 包一层函数或包装成新的类
No.20 纯稚的数据类 (Data Class)
解决方案:
- 将相关操作封装进去，减少public成员变量
No.21 被拒绝的遗赠 (Refused Bequest)
表现：父类里面方法很多，子类只用有限几个
实质：继承体系设计错误
解决方案:
- 用代理替代继承关系
No.22 过多注释 (Comments)
解决方案:
- 避免用注释解释代码，而是说明代码的目的，背景等，好代码自己会说话
参考资料
《重构-改善既有代码的设计》
https://sourcemaking.com/refactoring/smells
