【读书笔记-重构与模式】 代码坏味~

<重构与模式>中指出：

   重构，也就是对既有代码设计的改善，要求你首先知道什么样的代码需要改善。

   书中给出了12种代码坏味的表现：

 

 1  重复代码 2. 方法过长 3. 条件逻辑太复杂 4. 基本类型迷恋 5. 不恰当的暴露 6. 解决方案蔓延 7. 异曲同工的类 8. 冗赘类 9. 类过大 10 分支语句 11 组合爆炸 12 怪异解决方案。

另一份代码坏味列表：

类型

说明

Duplicated Code

（重复代码）

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

Long Method

（过长函数）

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

我们遵循这样一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。

Large Class

（过大的类）

不要尝试利用单个类去做太多事情。这也是面向对象“单一职责”原则。

Long Parameter List

（过长参数列）

函数需要的东西多半可以在函数的宿主类中找到。面向对象程序中的函数，其参数列通常比在传统程序中短得多。

Divergent Change

（发散式变化）

如果某个类经常因为不同的原因在不同的方向上发生变化，Divergent Change就出现了。

Shotgun Surgery

（霰弹式修改）

如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是Shotgun Surgery。

Feature Envy

（依恋情结）

函数对某个类的兴趣高过对自己所处类的兴趣。这种孺慕之情最通常的焦点便是数据。

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

最根本的原则是：将总是一起变化的东西放在一块儿。努力保持变化只在一地发生。

Data Clumps

（数据泥团）

一个好的评判办法是：删掉众多数据中的一项。这么做，其他数据有没有因而失去意义？如果它们不再有意义，这就是个明确信号：你应该为它们产生一个新对象。

所有的类将会组成一个小小的社会，每个类都会在其中发挥价值。

Primitive Obsession

（基本类型偏执）

对象的一个极大的价值在于：它们模糊（甚至打破）了横亘于基本数据和体积较大的类之间的界限。

Switch Statements

（switch惊悚现身）

少用switch（或case）语句。面向对象中的多态概念可为此带来优雅的解决办法。

Parallel Inheritance Hierarchies

（平行继承体系）

每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类。这时PIH就出现了。

消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。

Lazy Class

（冗赘类）

如果一个类的所得不值其身价，它就应该消失。

Speculative Generality

（夸夸其谈未来性）

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

Temporary Field

（令人迷惑的暂时字段）

有时你会看到这样的对象：其内某个实例变量仅为某种特定情况而设。这样的代码让人不易理解，因为你通常认为对象在所有时候都需要它的所有变量。在变量未被使用的情况下猜测当初其设置目的，会让你发疯的。

Message Chains

（过度耦合的消息链）

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

通常更好的选择是：先观察消息链最终得到的对象是用来干什么的。

Middle Man

（中间人）

对象的基本特征之一就是封装——对外部世界隐藏其内部细节。封装往往伴随委托。但是不要过度运用委托。

Inappropriate Intimacy

（狎昵关系）

有时候你会看到两个类过于亲密，花费太多时间去探究彼此的private成分。类之间过分狎昵的关系必须拆散。

继承往往造成过度亲密。如果你觉得该让这个孩子独自生活了，请让他离开继承体系。

Alternative Classes with Different Interfaces

（异曲同工的类）

两个函数做同一件事，却有着不同的签名，势必只能保留一个。

Incomplete Library Class

（不完美的类库）

库类构筑者没有未卜先知的能力，我们不能因此责怪他们。麻烦的是我们不可能修改其中的类使它完成我们希望完成的工作，要想其它办法解决问题。

Data Class

（纯稚的数据类）

Data Class就像小孩子，作为一个起点很好，但若要让它们像成熟的对象那样参与整个系统的工作，它们就必须承担一定责任。

Refused Bequest

（被拒绝的遗赠）

如果子类复用了超类的行为（实现），却又不愿意支持超类的接口，Refused Bequest的坏味道就会变得浓烈。拒绝继承超类的实现，这一点我们不介意。但是如果拒绝继承超类的接口，我们不以为然。

Comments

（过多的注释）

注释是好的编程习惯，但是利用注释掩盖糟糕的代码就不对了。