《重构-改善既有代码的设计》读书笔记（二）

12[/b]、Lazy Class – [/b]冗赘类[/b]
对于几乎没有用的类，运用inline class 将其功能移动。去除这些不值得维护的类。

[/b]
13[/b]、Speculative Generality – [/b]夸夸其谈未来性[/b]
对于你现在用不到，觉得总有一天会用到的代码，要警惕。用不上的装置总会挡我们的路，所以要尽量搬开。例如，没有太大作用的abstract class，非必要的委托，没有用到的函数参数，或者是函数的名称带有多余的抽像的意味。

[/b]
14[/b]、Temporary Field – [/b]令人迷惑的暂时值域[/b]
如果某些变量只是为了某种特定情况而设的，常会让人不理解

[/b]
15[/b]、Message Chains – [/b]过度耦合的消息链[/b]
你常会看到用户向一个对象请求另一个对象，然后再向后者请求另一对像，然后再继续…形成了一个强耦合的消息链。一旦对像间的关系发生任何变化，客户不得不做出大量修改。

[/b]
16[/b]、Middle Man –[/b]中间转手人[/b]
Encapsulation – 封装，对外部世界隐藏内部细节。封装常常伴随delegation（委托），但如果被过度使用，就必须得重新考虑。如果你看到某个class中有一半的函数都委托给其它class，这时就是强烈地信号。

[/b]
17[/b]、Inappropriate Intimacy – [/b]狎昵关系[/b]
二个类之间的关系联系太过紧密，造成强耦合。一般来讲，继承往往会造成这样结果，因为subclass对superclass的了解总是超过superclass的主观愿望。

[/b]
18[/b]、Alternative Classed with Different Interfaces? -- [/b]异曲同工的类[/b]
二个函数做同样的事，却有着不同的名字。你该知道怎么处理了吧。

[/b]
19[/b]、Incomplete Library Class – [/b]不完美的程序库类[/b]
我们在运用程序类库的时候，发现它并不是真正适合需要。

[/b]
20[/b]、Data Class [/b]纯稚的数据类[/b]
找到Data Class 中可能存在的public的值域，如果它的fields中存在容器类，就要小心地检查是不是得到了有效的封装。

[/b]
21[/b]、Refused Bequest – [/b]被拒绝的遗赠[/b]
Subclasses 应该继承superclass的函数和数据，但是如果subclass并不需要superclass的中某些功能，该怎么办呢。

[/b]
22[/b]、Comments – [/b]过多的注释[/b]这里讲并不是你不应当写注释，而是说，如果一段代码有着长长的注释，实际上说明这段代码是不容易看懂的，如果到处都需要大段的注释，那整体程序的可读性就大大困难；如果你一定需要一段注释来说明，那么先试着重构，把可提出去Method 找出来，如果这之后仍然需要注释来解释其行为，那就要试着Rename，使其拥有有一个能说明其行为的类名或方法名，程序可读性会大大增强