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

其实看了重构之后，发现重构和设计模式有很多很多相通的地方，或者有着同样的目的。你完全可以参考设计模式的原则来修改已有的代码。

1.单一职责原则

2.开放--封闭原则

3.依赖倒装原则

4.迪米特原则（类松耦合）

笔者也在《重构》这本书中大量的谈到各种设计模式，所以再次推荐大家去看看 设计模式

其实很多时候我们不复审自己的代码的话，是很难发现自己编写代码的不足的。而且就算是复审了也很难发现问题，反正能实现功能就行了。

所以重构这本就是总结那些大牛们总结出的经验结晶，能教我们怎么发现这些不是bug的问题，并解决它们。

什么是重构？

这是定义：

　　重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。

　　重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

　　说人话：就是已有代码太糙了，又臭又长，既不方便修改，也不方便复用...（不符合各种设计原则），需要进行修改加工整容。

为什么需要重构？

因为可以升职加薪，赢取白富美呀。

什么时候重构？

1.难以阅读的程序，难以修改；

2.逻辑重复的程序，难以修改；

3.添加新行为时需要修改已有代码的程序，难以修改；

4.带复杂条件逻辑的程序，难以修改；

因此我们希望程序：

　　1.阅读容易；

　　2.所有逻辑都只在唯一地点指定；

　　3.新的改动不会危及现有行为；

　　4.尽可能简单表达条件逻辑；

代码的坏味道

当你闻到这些味道的时候，可能你的代码需要重构了。所以以下这些味道很重要。

1.重复代码（Duplicate Code）：

如果你在一个以上的地方看到相同的程序结构，那么可以肯定：设法将它们合而为一，程序会变得更好。

2.过长函数（Long Method）：

你应该积极分解函数。我们遵循这样一条原则：每当感觉需要以注释来说点什么的时候，我们就把需要说明的东西写进一个独立的函数中，并以其用途命名。

3.过大的类（Large Class）：

如果想利用单个类做过多的事情，其内往往就会太多实例变量。

4.过长参数列（Long Parameter List）：

如果参数列太长或者变化太频繁，你就需要重新考虑自己的依赖结构了。

5.发散式变化（Divergent Change）：

如果某个类经常因为不同的原因在不同的方向上发生变化。（每个对象只应该因为一种变化而修改）

6.散弹式修改（Shotgun Surgery）：

与发散式变化相反，如果每遇到某种变化，都需要在许多不同的类内做出许多修改。

7.依恋情结（Feature Envy）：

对象技术的全部要点在于：将数据和对数据的操作行为包装在一起。 坏气味：函数对某个类的兴趣高于对自己所处类的兴趣。

有个原则：判断哪个类拥有最多被此函数使用的数据，然后就把这个函数和那些数据摆咋一起。

8.数据泥团（Data Clumps）:

你常常看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。这些总绑在一起出现的数据应该拥有属于它们自己的对象。

而且：一旦拥有新对象，你就可以着手寻找Featrue Envy，这可以帮你指出能够移至新类中的种种程序行为。

9.基本类型偏执狂（Primitive Obsession）:

对象技术的新手通常不愿意在小任务上运用小对象。例如单独由数值、币种两个字段组成的money类。

10.switch惊悚现身（Switch Statement）:

面向对象程序的一个最明显的特征就是：少用switch语句。大多数时候，一看到switch语句，你就应该考虑以多态来替换它。可以和策略模式一起食用。

11.平行继承体系（Paralle Inheritance Hierarchies）:

其实是shotgun sergery的特殊情况。如果每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类。

12.冗赘类（Lazy Class）:

如果一个类的所得不值其身价，它就应该消失。程序届也不喜欢懒的类。

13.夸夸其谈未来性（Speculative Generality）：

当有人说“噢，我想我们总有一天需要做这事”，并因而企图以各式各样的钩子和特殊情况来处理一些非必要的事情。

14.令人迷惑的暂时字段（Template Field）：

有时你会看到这样的对象：其内某个实例变量仅为某种特定情况而设。

15.过度耦合的消息链（Message Chains）：

如果你看到用户向一个对象请求另一个对象，然后向后者请求另一个对象，然后再请求另一个对象...这就是消息链。

16.中间人（Middle Man）：

人们可能过度的运用代理（中间人）。你也许会看到某个接口有一半的函数都委托给其他类，这样就是过度运用。

17.狎昵xiá nì关系（Inappropriate Intimacy）:

有时你会看到两个类过于亲密，花费太多时间去探究彼此的private成分。

18.异曲同工的类（Alternative Classes with Different Interface）：

当两个函数做同一件事，却有着不同的签名。

19.不完美的类库（Incomplete Library Class）：

麻烦的是类库往往构造的不够好，或者有些部分不适用了，而且我们往往不可能让我们修改其中的类使它完成工作。

20.幼稚的数据类（Data Class）：

所谓Data Class是指：他们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外别无长物。

21.被拒绝的遗赠（Refused Bequest）：

子类应该继承超类的函数和数据。但如果它们不想或不需要继承，或者只是需要其中少数元素。

22.过多的注释（Comment）：

常常会有这样的情况：你看到一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕，这种情况发生次数之多，很惊人。

当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。

下一篇详细讲讲怎么除去臭味。