#重构
- 重构改变了开发程序
- 重构改变了修改程序
- 重构改变了数据库维护
- http://www.refactoring.com/catalog/extractMethod.html ========
- 使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构
- 消除重复代码，可以确定所有事务和行为在代码中只表述一次，【这正是优秀设计的根本】
- 想要它所什么-->告诉它做什么，其核心思想是【准确说出我所要的】
- 早期重构-->【擦掉窗户上的污垢，使你看得更远】
- 良好的设计师维持软件开发速度的根本，重构可以帮助你更快的开发软件，【它阻止软件腐败变质】
- 三次法则->【事不过三，三则重构】 第一次：只管去做 第二次：做类似的事情产生反感 第三次：在做类似事，就应该重构
- 计算机科学是这样一门科学：它相信所有问题都可以通过增加一个间接层来解决
- 修改旧函数时，应该保留旧函数，让旧函数调用新函数，并将旧函数标记为@deprecated【表示反对】
- 如果在所有可能变化出现的地点都建立起灵活性，整个系统的复杂度和维护度都会大大提高
- 重构可以带来更简单的设计，同时又不损失灵活性，这也降低了设计过程的难度，减轻了设计压力。
- 语义保护性重构
- 培养重构的判断力
-
判断一个类内部有多少实例变量算是太大
-
一个函数内有多少行代码才算太长
-
Duplicated Code 【重复代码】
-
Long Method 【过长函数】
-
Large Class 【过大的类】
-
Long Parameter List【过长参数】
-
Diverent Change 【发散式变化：一个类受多种变化的影响】
-
Shotgun Surgery 【散弹式修改：一种变化引发多个类相应修改】
-
Feature Envy 【依恋情结】
-
Data Clumps 【数据泥团】
-
Primitive Obsession 【基本类型偏执】
如果在一个以上的地点看到相同的程序结构，那么可以肯定，设法将它们合而为一
-
小函数的利益
- 解释能力
- 共享能力
- 选择能力
#受控异常 VS 非受控异常
控异常：Checked Exception，这类异常必须写try{}catch{}，或者throw抛出，否则编译通不过。
非受控异常：Unchecked Exception，这类异常也叫做运行时异常（与非受控异常 字数相等），
这类异常不需要try{}catch{}，也不需要throw抛出，编译能通过。
为什么要使用非受控异常？为了简化代码。
试想一下，如果所有可能出现异常的地方（比如访问数组元素可能会越界、
调用对象方法，对象可能为null），我们都写try{}catch{}，或者throw 抛出，
那么代码肯定冗余的不成样子了。也就是说，
采用非受控异常（运行时异常）可以减少代码的污染。
对于受控异常，因为必须要写try{}catch{}，或者throw抛出，没什么可讲的。
对于非受控异常（运行时异常），因为不需要额外处理，
也能编译通过，我们可以进行预先检查，
比如访问数组元素时，我们预先检查是否越界，
调用对象方法时，预先检查对象是否为null