第九章：简化条件表达式
-
分解条件表达式
将if-then-else对应的三个段落分解为三个函数。
动机：条件逻辑语句会降低程序的可读性，而函数名可以清楚地表明每个分支的作用。（到这里我们可以发现，跟前面函数提取的手法一样，都是利用函数名可以有注释的效果）。这里面反直接的东西就是，分支可能会很短，所以不想提取。但是，尽管这些条件很短，在代码意图和代码自身之间往往存在不小的差距。 -
合并条件表达式
在条件检查不同的情况下，最终执行的语句确完全相同，这个手法将这些检查合并并提炼称谓一个函数进行判断。但在这些判断条件的确彼此独立，不应该合并，那么久不要使用本项重构。有时合并并不需要将条件完全合并，只需要合并部分条件那也是好的。
动机：实际上只有一次条件检查，只不过有多个并列条件需要检查而已。 -
合并重复的条件片段
将各个分支相同的操作移动到分支外面
动机：这样代码才能更清楚地表明哪些东西随条件的变化而变化，哪些东西保持不变 -
移除控制标记
用break，return，continue取代控制标记，优先使用return，因为return清楚地表明了程序不再执行，返回。
动机：控制标记使得代码的可读性变差 -
以卫语句取代嵌套条件表达式
使用卫语句表现所有的特殊情况，还有一种是如果A就做B，这个时候也可以先判断!A返回，然后再去做B。
动机：如果某个条件极其罕见，就应该单独检查该条件，并在该条件为真时立刻从条件返回，这样的语句常常被称为“卫语句”。这个手法的精髓是，给特殊情况以特别的重视。 -
以多态取代条件表达式
这条很熟悉了，不写了 -
引入空对象
空对象中对原来的各种行为重新定义为我们大多数情况下希望的空对象的行为，这样其他代码就不用针对对象为null的时候做特殊处理，可以做统一的处理。 -
引入断言
动机：断言可以提高程序的可读性，让读者知道什么情况是应该避免的；另外可以检测出异常。
第10章：简化函数调用
-
将查询函数和修改函数分离
如果遇到一个“既有返回值又有副作用”的函数，就应该试着将查询动作从修改动作中分割出来。一般来说我们在查询到变量的时候对变量顺便做一些修改，但这个手法是先将变量查询出来，再在另外的函数中修改。
动机：查询函数使得我们需要操心的事情少了很多。 -
令函数携带参数 &以明确函数取代参数
这两个手法是函数和参数的转化，前者将函数相同部分提取为函数主体，参数作为变化部分，后者将不同的参数转化为不同的函数。
动机：前者可以提炼函数，使得逻辑更加清晰。但如果在某个参数有多种可能的值，而函数内又以条件表达式检查这些参数值，并根据不同的参数值做出不同的行为，那么就该用明确的函数取代参数。
修改前：
static final int ENGINEER = 0;
static final int SALESMAN = 1;
static final int MANAGER = 2;
static Employee create(int type) {
switch (type) {
case ENGINEER:
return new Engineer();
case SALESMAN:
return new Salesman();
case MANAGER:
return new Manager();
default:
throw new IllegalArgumentException("Incorrect type code
value");
}
}
修改后：
Employee kent = Employee.createEngineer()
-
保持对象完整
做法：如果一个对象的多个字段被输入到参数中，直接输入对象
动机：将来可能会要更多字段，不用进行修改；缩短过长的参数列；我自己还想到另外一个优点，那就是不用费心参数的名字，用对象.字段在某些情况下更清晰，也可能不会更清晰。弊端是：函数现在依赖的是整个对象，而不是只是一些值。
如果被调用函数使用了某个对象的很多字段，那对象很有可能需要用移动方法的手法移动到对象中去。
如果参数很多，而且没有定义对象，那么可能需要使用引入参数对象的手法。 -
以函数取代参数
函数调用后的结果作为参数作为参数输入到另外一个函数中，去到后者的参数，然后再其函数内，调用先前函数。
动机：缩减参数列的办法之一就是：看看参数端是否可以通过与调用端相同的计算来取得参数值。 -
以工厂函数取代构造函数
动机：？？ -
以异常取代错误码
动机：将正常代码和错误代码分开了。
网友评论