《重构改善既有代码的设计》-代码的坏味道(学习笔记 )

1、Duplicated Code 重复代码

两个函数拥有相同的表达式，通俗点说就是大家Copy的相同的代码，粘贴来粘贴去的代码会分为两种情况：在同一个类中，不在同一个类中。经常见到大家网上搜到一段代码，然后就Copy到项目中是使用。当A功能点需要用到自然就粘贴过去了，如果还有B、C、D.、E、F.....Z的功能点上用到了，依旧是复制粘贴过去，某天Copy的代码出现bug了或者增加新的功能，(-｡-;)那就等着改吧，有多少个地方就要改多少次。这时候懒的代价就出来了，咱们是接着懒，还是顺手重构呢？还是提炼函数吧。

继承同一个父类的不同子类有着相同的代码，那么先提炼公用函数，然后提升至父类中。

2、Long Method 过长函数

过长函数的特征：

做了多件事。往往是把一个函数写成面向过程，必然是一个函数做了多件事。如果分不清面向过程和面向对象是什么，那么请你尝试画思路图或者流程图，如果流程能分解那么说明，该函数是可以分解的。

往往有out、ref等参数。请尝试分解，用return 返回 out或 ref的参数。

拥有多层嵌套。如多层循环、多层if、多层switch，或者某一、两种组合起来嵌套。那么请分解，嵌套中至多只能有一条语句。

拥有过多临时变量，请用函数代替这些变量。

3、Large Class 过大的类

过大的类往往拥有太多的变量与过多的函数，以及大量的注释。

4、Long Parameter List 过长参数列

参数超过3个以上就要考虑提炼成一个实体，或者其它方式，思考是否我真的需要这些参数，或者分解该函数。尤其要杜绝out与ref传递参数。

5、Divergent Change 发散式变化

一个类受多种变化的影响。简单点说，该类违反了单一职责，担任了过多的职责，所以会受多种变化的影响。

6、Shotgun Surgery 散弹式修改

一种变化引发多个类进行修改。简单点说，增加某项功能时只在较小范围内进行修改。如果出现超过2个类以上的地方修改那么就要注意了。是否该提炼变化为其封装至新的类中。散弹式修改与发散式变化正好相反。

7、Feature Envy 依恋情结

一个类与另一个类有太多合作导致高度耦合导致数据之间的依恋严重。典型列子，一个函数往往会调用其他类的数据或函数，核心的焦点是数据。其调用其他类的数据或函数超级多，很多时候为了取值，或者计算某个值时。从其他类处调用了几乎大半的取值函数。那么怎么处理这种情况呢？部分计算需要提炼函数或者搬迁函数降低耦合度（思念之苦）。如出现多地需要修改，需注意可以单独加一层中间层来处理。

8、Data Clumps 数据泥团

数据泥团是指两个类中相同的字段或函数中相同的参数。（字段或参数超过3项后考虑提炼实体类。）

9、Primitive Obsession 基本类型偏执

这一节理解的不是很透彻。主要是说数据。比如：保险中的起止与结束日期，应该建立一个新的类，而不是【string startDate，string endData】两个字符串类型或者日期类型来表示。①将一些数据值替换成对象。②用类取代类型码。（对书上的列子表示不是很赞同）

10、Switch Statements 惊辣现身Switch

11、Parallel Inheritance Hierarchies 平行继承体系

12、Lazy Class 冗赘类

13、Speculative Generality 夸夸其谈未来性

14、Temporary Field 令人迷惑的暂时字段

15、Message Chains 过度耦合的消息链

16、Middle Man 中间人

17、Inappropriate Intimacy狎昵关系

18、Alternative Classes with Different Interfaces 异曲同工的类

19、Incomplete Library Class 不完美的库类

20、Data Class 纯稚的数据类

21、Refused Bequest 被拒绝的遗赠

22、Comments 过多的注释