java feature envy_《重构-改善既有代码的设计 第3章代码的坏味道》学习笔记

何时重构、何时停止重构

学会判断一个类内有多少实例变量算是太大、一个函数内有多少行代码算太长

下面是对各种坏味道的简短汇集和解释

Duplicated Code

Long Method

Large Class

Long Parameter List

Divergent Change(多种变化导致一个类的变化)

Shotgun Surgery(一种变化导致多个类的变化)

Feature Envy(函数对某个类的兴趣高于对自己所处类的兴趣。)

Data Clumps(多个经常一起出现的字段或参数)

Primitive Obsession(不使用基本类型而使用类)

Switch Statements(同样的switch语句散布于不同地点。)

Parallel Inheritance Hierarchies(每当你为某个类增加一个子类，同时也必须为另一个类相应地增加一个子类。)

Lazy Class(冗赘类)

Speculative Generality(夸夸其谈未来性)

如果某个抽象类其实没有太大作用->Collapse Hierarchy。

不必要的委托可运用Inline Class除掉。

函数的某些参数未被用上->Remove Parameter。

函数名称带有多余的抽象意味->Rename Method，让它现实一些。

函数或类的唯一用户是测试用例，把它们连同其测试用例一并删掉。但如果它们的用途是帮助测试用例检测正当功能，则必须刀下留人。

Temporary Field(某个类内某个实例变量仅为某种特殊情况而设。)

Message Chains(用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象.... )

Middle Man(过度运用委托)

Inappropriate Intimacy(两个类过于亲密，花费太多时间去探究彼此的private成分。 )

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

Incomplete Library Class(不完美的类库)

Data Class(限制属性的访问性)

Refused Bequest(被拒绝的遗赠)

子类破坏父类的接口

Comments(过多的注释)

3.1 Duplicated Code(重复代码)

同一个类的两个函数含有相同的表达式(Extract Method)

两个互为兄弟的子类内含有相同表达式:对两个类使用Extract Method，然后再对被提炼出来的代码使用Pull Up Method,将它推入超类内。

如果代码之间只是类似，并非完全相同，那么就得运用Extract Method将相似部分和差异部分分割开，构成单独一个函数。然后可能发现可以运用Form Template Method获得一个Template Method设计模式。有些函数以不同的算法做相同的事，你可以选择其中较清晰的一个，并使用Subsitute Algorithm将其他函数的算法替换掉。

如果两个毫不相关的类出现Duplicated Code，就应该考虑对其中一个使用Extract Class,将重复代码提炼到一个独立类中，然后在另一个类内使用这个新类。

但是重复代码所在的函数也可能的确只应该属于某个类，另一个类只能调用它，抑或这个函数可能属于第三个类，而另外两个类应该引用某个类。必须决定这个函数放在哪儿最合适，并确保它被安置后就不会再在其他任何地方出现。

3.2 Long Method(过长函数)

拥有短函数的对象会活得比较好、比较长。

“间接层”所能带来的全部利益——解释能力、共享能力、选择能力——都是由小型函数支持的。

程序愈长愈难理解。

早期的编程语言中，子程序调用需要额外开销，这使得人不太乐意使用小函数。

现在的OO语言进程内的函数调用开销可以忽略不计。

让小函数容易理解的真正关键