重构读书笔记

2013-6-3
When Should You Refactor?
The Rule of Three
Refactor When You Add Function
Refactor When You Need to Fix a Bug
Refactor As You Do a Code Review
Programs have two kinds of value: what they can do for you today and
what they can do for you tomorrow.

If you can get today's work done today,
but you do it in such a way that you can't possibly get tomorrow's work
done tomorrow, then you lose.
如果一种设计方式今天工作，但是明天就不能工作了，那么这种设计就是失败的。

What is it that makes programs hard to work with? Four things I can think
of as I am typing this are as follows:
·  Programs that are hard to read are hard to modify.
·  Programs that have duplicated logic are hard to modify.
·  Programs that require additional behavior that requires you to change running code are hard to modify.
   要改变现有运行中系统代码的难以修改（对应设计原则：对扩展开放，对修改关闭）
·  Programs with complex conditional logic are hard to modify.
So, we want programs that are easy to read, that have all logic specified
in one and only one place, that do not allow changes to endanger
existing behavior, and that allow conditional logic to be expressed as
simply as possible.

Refactoring tends to break big objects into several smaller
ones and big methods into several smaller ones.

1,消除重复代码
情况一：同一个类的两个函数具有相同的表达式。解决办法是重复代码提炼到一个方法中被调用即可。
情况二：两个互为兄弟的子类内含有相同的表达式。解决办法是对相同与不同部分分别提炼出来再采用模板方法设计模式处理。
情况三：两个互不相关的类出现重复代码时，应该将重复代码提取一个独立的类中由其它类分别调用。

2,长函数要尽力分解为短函数。

每当感觉需要以注释来说明点什么的时候, 我们就把需要 说明的东西写进一个独立的函数中,并以其 用途(而非实现手法) 用途(而非实现手法)命名。
使用短函数的系统会活得比较长命。

3,将过长的参数列提炼到一个参数对象中。

4,每当代码上方有注释时，就可以考虑将注释的代码提取到一个函数中，并在注释的基础上为函数命名。

条件表达式和循环常常也是提炼函数的信号。
让一个小函数易于理解的关键是给它起一个能自解释作用的好名字，这样就不用看方法中具体写什么了。

5,一个类做事情太多，有太多实例变量，有太多代码，就要进行过大的类的分解
可以选择类内彼此相关的变量提炼到一个新类中，比如类内的数个变量具有相同的前缀或结尾。
当一个类没有在所有时刻使用所有实例变量时，就可以执行多次提炼小的高内聚类的操作。（面向对象的核心就是将数据和对数据的操作封装到一个对象中）
分解技巧：先确定客户端如何使用它们，然后为每种使用方式提炼出一个公开接口。
模块化原则：高内聚，松散耦合

过长参数列可以提炼为一个参数对象