加入重构手法

ymero · Jul 19, 2015 · 40d098e · 40d098e
1 parent 0b3f400
commit 40d098e
Show file tree

Hide file tree

Showing 12 changed files with 63 additions and 0 deletions.
diff --git a/重构-Extract Class.png b/重构-Extract Class.png
diff --git a/重构-Extract Method.png b/重构-Extract Method.png
diff --git a/重构-Extract Subclass.png b/重构-Extract Subclass.png
diff --git a/重构-Form Template Method.png b/重构-Form Template Method.png
diff --git a/重构-Introduce Parameter Object.png b/重构-Introduce Parameter Object.png
diff --git a/重构-Preserve Whole Object.png b/重构-Preserve Whole Object.png
diff --git a/重构-Pull Up Method.png b/重构-Pull Up Method.png
diff --git a/重构-Replace Method with Method Objec.png b/重构-Replace Method with Method Objec.png
diff --git a/重构-Replace Parameter with Method.png b/重构-Replace Parameter with Method.png
diff --git a/重构-Replace Temp with Query.png b/重构-Replace Temp with Query.png
diff --git a/重构-Substitute Algorithm.png b/重构-Substitute Algorithm.png
diff --git a/重构.md b/重构.md
@@ -1,4 +1,8 @@
 #重构
+- 重构改变了开发程序
+- 重构改变了修改程序
+- 重构改变了数据库维护
+- http://www.refactoring.com/catalog/extractMethod.html
 ========
 * 使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构
 * 消除重复代码，可以确定所有事务和行为在代码中只表述一次，【这正是优秀设计的根本】
@@ -9,3 +13,62 @@
 	第一次：只管去做
 	第二次：做类似的事情产生反感
 	第三次：在做类似事，就应该重构
+* 计算机科学是这样一门科学：它相信所有问题都可以通过增加一个间接层来解决
+* 修改旧函数时，应该保留旧函数，让旧函数调用新函数，并将旧函数标记为@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
+```