《重构》-3-代码的坏味道-读书笔记

前言

你必须培养出自己的判断力，学会判断一个class内有多少instance变量算是太大、一个函数内有多少行代码才算太长

有些方法名词可能在后面的读书笔记中提到：本章目的是建立一个整体感觉。

实例（instance）

提炼类（Extract Class）

提炼方法（Extract Method）

分解条件式（Decompose Conditional）

折叠继承体系（Collapse Hierarchy）

将类内联化（Inline Class）

隐藏【委托关系】（Hide Delegate）

以委托取代继承（Replace Inheritance with Delegation）

1、重复的代码（Duplicated Code）

（1）如果两个毫不相关的classes内出现Duplicated Code，你应该考虑对其中一个使用Extract Class，将重复代码提炼到一个独立的class中，然后在另一个class内使用这个新class。但是，重复代码所在的函数也可能的确只应该属于某个class

2、过长函数（Long Method）

（1）【间接层】所能带来的全部利益--解析能力、共享能力、选择能力--都是由小型函数支持的（在第2章的读书笔记中有提及）

（2）因为必须经常转换上下文去看看子程序做了什么。如果你能给函数起个好名字，读者就可以通过名字了解函数的作用，根本不必去看其中写了些什么。

（3）关键不在于函数的长度，而在于函数【做什么】和【如何做】之间的语义距离，一个方法如果做的事情过多，将很难对其中的代码进行重用，也难以理解代码中的控制含义，一般分开几个方法，对于碰见有部分相同或修复BUG是易于构建开发思路和维护代码

（4）如果函数内有大量的参数和临时变量，它们会对你的函数提炼形成阻碍。如果你尝试用Extract Method，最终就会把许多这些参数和临时变量当作参数。

（5）如果代码前方有一行注释，就是在提醒你：可以将这段代码替换成一个函数，条件式和循环常常也是提炼的信号，你可以使用Decompose Conditional处理条件式。至于循环，你应该将循环和其内的代码提炼到一个独立函数中。

3、过大类（Large Class）

（1）如果想利用单一class做太多事情，其内往往就会出现太多instance变量。一旦如此，Duplicated Code 也就接踵而至了。

4、
a99c
过长参数列（Long Parameter List）

（1）把函数所需的所有东西都以参数传递进去。这可以理解，因为除此之外就只能选择全局数据，而全局数据是邪恶的东西。对象技术改变了这一情况，因为如果你手上没有你所需要的东西，总可以叫另一个对象给你。

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

5、发散式变化（Divergent Change）
6、散弹式修改（Shotgun Surgery）

7、依恋情结（Feature Envy）

（1）有时候函数中只有一部分受这种依恋之苦，这时候你应该使用Extract Method把这一部分提炼到独立函数中。

8、数据泥团（Data Clumps）

（1）喜欢成群结队地待在一块儿。你常常可以在很多地方看到相同的三或四笔数据项：两个classes内的相同值域（field）、许多函数签名式（signature）中的相同参数。这些【总是绑在一起出现的数据】真应该放进属于它们自己的对象中。

（2）缩短值域个数和参数个数，当然可以除一些坏味道，但更重要的是：一旦拥有新对象，你就有机会让程序散发一种芳香。

9、基本型别偏执（Primitive Obsession）

10、switch惊速现身（Switch Statements）

（1）少用switch（或case）语句。

（2）一看到switch语句你就应该考虑以【多态】来替换它

11、平行继承体系（Parallel lnheritance Hierarchies）

（1）如果你发现某个继承体系的class名称前缀和另一个继承体系的class名称前缀完全相同，便是闻到了这种坏味道

12、多余类（Laze Class）

（1）如果某些subclass没有足够的工作，试试Collapse hierarchy。对于几乎没用的组件，你应该以Inline Class 对付它们，提供一系类把一些没有价值的类去除的方法

13、夸夸其谈未来性（Speculative Generality）

（1）我想我们总有一天需要做这事（过度开发），并因而企图以各式各样的挂勾（hooks）和特殊情况处理一些非必要的事情，这种坏味道就出现了。

（2）如果函数或class的惟一用户是test cases（测试用例），这就飘出了坏味道，如果这边代码或实例只是作为一个测试的用例之后应该把它删除或屏蔽，以防被其它人利用。

14、令人迷惑的暂时值域（Temporary Field）

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

（1）如果你看到用户向一个对象索求（request）另一个对象，然后再向后者索求另一个对象，然后再索求另一个对象------这就是Message Chain。

（2）一旦对象间的关系发生任何变化，客户端就不得不作出相应修改。

（3）这时候你应该使用Hide Delegate。你可以在Message Chain的不同位置进行这种重构手法。

16、中间转手人

（1）但是人们可能过度运用委托。你也许会看到某个class接口有一半的函数都委托给其它class，这样就是过度运用，这是你应该移除重剑类。

17、过度亲密（Inappropriate Intimacy）

（1）有时你会看到两个classes过于亲密，花费太多时间去探究彼此的private成分。如果这发生在两个【人】之间，我们不必做卫道之士：但对于classes，我们希望它们严守清规。

（2）继承往往造成过度亲密，因为subclass对superclass的了解总是超过superclass的主观愿望。如果你觉得该让这个孩子独自生活了，请运用Replace Inheritance with Delegation 让它离开继承体系。

18、异曲同工的类（Alternative Classes with Different Interfaces）
19、不完美的程序库类（Incomplete Library Class）
20、纯数据类（Data class）
21、被拒绝的遗赠（Refused Bequest）

22、过多的注释（Comments）

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

（2）注释有时候已经变得多余，因为代码已经清楚说明了一切，尽量写出高素质的代码，减少注释。