《重构|《重构改善既有代码的设计》第9章简化条件表达式《重构改善既有代码的设计》

前言条件逻辑有可能十分复杂，本章提供一些重构手法，专门用来简化它们。
1. Decompose Conditional（分解条件表达式）概要：针对复杂的条件（if-then-else）语句
做法：从if、then、else三个段落中分别提炼出独立函数
2. Consolidate Conditional Expression（合并条件表达式）一系列条件检查，都得到相同的结果。
合并为一个条件表达式，并将这个条件表达式提炼成一个独立函数。
【《重构|《重构改善既有代码的设计》第9章简化条件表达式】重构前

double disabilityAmount() {if(seniority < 2) return 0; if(monthsDisabled > 12) return 0; if(isPartTime) return 0; // compute the disability amount}

重构后

double disabilityAmount() {if(seniority < 2 || monthsDisabled > 12 || isPartTime)return 0; // compute the disability amount}

注意不适用条件：这些检查的确彼此独立。
3. Consolidate Duplicate Conditional Fragments（合并重复的条件片段）重构前

if(isSpecialDeal()) {total = price * 0.95; send(); }else {total = price * 0.98; send(); }

重构后

if(isSpecialDeal()) {total = price * 0.95; }else {total = price * 0.98; }send();

一组条件表达式的所有分支都执行了相同的代码段，此时应该把这个代码段移到条件表达式的外面，才能更清楚地看到哪些东西随条件变化，哪些不变。
4. Remove control flag（移除控制标记）在一系列布尔表达式中，某个变量带有“控制标记’的作用。
以break或return语句取代控制标记。
动机：在一系列条件表达式中，常常会看到用以判断何时停止条件检查的控制标记。这样的标记带来的麻烦超过了它所带来的便利。人们之所以会使用这样的控制标记，因为结构化编程原则告诉他们：每个子程序只能有一个入口和出口。“单一出口“原则会让你在代码中加入让人讨厌的控制标记，大大降低条件表达式的可读性。这就是编程语言提供break和continue语句的原因：用它们跳出复杂的条件语句。去掉控制标记所产生的效果往往让你大吃一惊：条件语句真正的用途会清晰得多。
做法：

1、对控制标记的处理，最显而易见的办法就是使用break或continue语句。
2、找出让你跳出这段逻辑的控制标记值。
3、找出对标记变量赋值的语句，代以恰当的break或continue语句。
4、每次替换后，编译并测试。

重构前

void checkSecurity(String[] people) {boolean found = false; for(int i=0; i < people.length; i++) {if(!found) {if(people[i].equals("Don")) {sendAlert(); found = true; }if(people[i].equals("John")) {sendAlert(); found = true; }}}}

重构后

void checkSecurity(String[] people) {for(int i=0; i < people.length; i++) {if(people[i].equals("Don")) {sendAlert(); break; }if(people[i].equals("John")) {sendAlert(); break; }}}

5. Replace Nested Conditional with Cuard Clauses（以卫语句取代嵌套条件表达式）重构前

double getPayAmount() {double result; if(isDead) result = deadAmount(); else {if(isRetired) result = retiredAmount(); else result = normalAmount(); }return result; }

重构后

double getPayAmount() {if(isDead) return deadAmount(); if(isRetired) return retiredAmount(); return normalAmount(); }

6. Replace Conditional with Polymorphism（以多态取代嵌套条件表达式）重构前

public class Employee {private EmployeeType type; private int monthlySalary = 3000; private int commission = 2000; private int bonus = 5000; public Employee(EmployeeType employeeType) {this.type = employeeType; }int payAmount() {switch (getType()) {//根据不同员工类型，返回不同的薪水case EmployeeType.ENGINEER:return monthlySalary; case EmployeeType.SALESMAN:return monthlySalary + commission; case EmployeeType.MANAGER:return monthlySalary + bonus; default:throw new RuntimeException("Incorrect Employee"); }}int getType() {return type.getTypeCode(); }abstract class EmployeeType {public static final int ENGINEER = 1; public static final int SALESMAN = 2; public static final int MANAGER = 3; abstract int getTypeCode(); }class Engineer extends EmployeeType {@Overrideint getTypeCode() {return ENGINEER; }}class Salesman extends EmployeeType {@Overrideint getTypeCode() {return SALESMAN; }}class Manager extends EmployeeType {@Overrideint getTypeCode() {return MANAGER; }}}

重构后

public class Employee {private EmployeeType type; public Employee(EmployeeType employeeType) {this.type = employeeType; }int payAmount() {return type.payAmount(this); }abstract class EmployeeType {public static final int ENGINEER = 1; public static final int SALESMAN = 2; public static final int MANAGER = 3; abstract int payAmount(Employee employee); }class Engineer extends EmployeeType {@Overrideint payAmount(Employee employee) {return employee.getMonthlySalary(); }}class Salesman extends EmployeeType {@Overrideint payAmount(Employee employee) {return employee.getMonthlySalary() + employee.getCommission(); }}class Manager extends EmployeeType {@Overrideint payAmount(Employee employee) {return employee.getMonthlySalary() + employee.getBonus(); }}public int getMonthlySalary() {return 3000; }public int getCommission() {return 2000; }public int getBonus() {return 5000; }}

优化动机：
根据对象的不同类型而采取不同的行为，多态可以使你不必编写明显的条件表达式。
获得的收益：
类的用户不需要了解这个子类，大大降低了系统各部分之间的依赖，易扩展。
7. Introduce Null Object（引入Null对象）你需要再三检查某对象是否为null
一家公用事业公司的系统以Site表示地点，庭院宅第house和集体公寓apartment都使用该公司的服务。任何时候每个地点都拥有一个顾客，顾客信息以Customer表示。
重构前

public class Site {private Customer customer; Customer getCustomer() {return customer; }class Customer {private String name, plan; public String getName() {return name; }public String getPlan() {return plan; }}}

上面的各种取值函数允许客户取得各种数据。

Customer customer = site.getCustomer(); String plan; if (customer == null) {plan = "nullPlan"; } else {plan = customer.getPlan(); }String name; if (customer == null) {name = "nullName"; } else {name = customer.getName(); }

但有时候一个地点的顾客搬走了，新顾客还没搬进了，此时这个地点就没有顾客。由于这种情况有可能发生，所以我们必须保证Customer的所有用户都能处理“Customer对象等于null”的情况。
此时就是使用空对象的时候了。
重构后

public class Site {private Customer customer; //这是重点Customer getCustomer() {return customer == null ? new NullCustomer() : customer; }class Customer {private String name, plan; public String getName() {return name; }public String getPlan() {return plan; }}class NullCustomer extends Customer {public String getName() {return "nullName"; }public String getPlan() {return "nullPlan"; }}}

接下来在访问Customer对象的地方，直接调用对应方法即可。

Customer customer = site.getCustomer(); String plan = customer.getPlan(); String name = customer.getName();

8. Introduce Assertion（引入断言）某一段代码需要对程序状态做出某种假设
重构前

double getExpenseLimit() {return expenseLimit != NULL_EXPENSE ? expenseLimit : primaryProject.getMemeberExpenseLimit(); }

重构后

double getExpenseLimit() {Assert.isTrue (expenseLimit != NULL_EXPENSE || primaryProject != null); return expenseLimit != NULL_EXPENSE ? expenseLimit : primaryProject.getMemeberExpenseLimit(); }

优化动机
常常会有这样一段代码：只有当某个条件为真时，该段代码才能正常运行。例如平方根计算只对正值才能进行，又例如某个对象可能假设其字段至少有一个不等于null。这样的假设通常并没有在代码中明确表现出来，使用断言能够明确标明这些假设。
获得的收益
断言可以作为交流与调试的辅助（实际上，程序最后的成品往往将断言统统删除）
交流角度，断言可以帮助程序阅读者理解代码所做的假设。
调试角度，断言可以在距离bug最近的地方抓住他们。
做法
如果程序员不犯错，断言就应该不会对系统运行造成任何影响，所以加入断言永远不会影响程序的行为。
如果你发现代码假设某个条件始终为真，就加入一个断言明确说明这种情况
注意，不要滥用断言。
请不要使用它来检查“你认为应该为真”的条件，请只使用它来检查“一定必须为真”的条件。你应该常常问自己：如果断言所指示的约束条件不能满足，代码是否仍能够正常运行？如果可以，就把断言拿掉。