代码整洁之道-<函数>

代码整洁之道一书相关读书笔记，整洁的代码是自解释的，阅读代码应该如同阅读一篇优秀的文章，见字知意，能够一下子明白大概的代码功能。代码首先要能读懂，其次才去要求功能实现。
作为开发者来说，在现在基本都讲究团队合作的工作方式下，规范远比功能重要，开发的功能也许在版本迭代中就不复存在了，但是规范却是一直存在的。
为了整洁的代码，就必须遵循一些统一的团队规范。混乱不堪连命名都无法取好的代码，只会给增加后续接手人员维护的成本

1.短小

函数的第一个规则就是要短小，第二条规则时还要更短小。

一个长达3000行的函数，你读着读着自己都厌恶了

代码块和缩进

if语句、else语句、while语句等，其中的代码块应该只有一行，该行大抵应该是一个函数调用语句，这样不但能保持函数短小，而且，因为块内调用的函数拥有较具有说明性的名称，从而增加了文档的价值

2.只做一件事

函数应该做一件事，做好这件事。只做这一件事

3.每个函数的一个抽象层级

要确保函数只做一件事，函数中语句都要在同一抽象层级上。一眼就能看出。

函数中不同抽象层级，往往让人迷惑，可能无法判断某个表达式是基础概念还是细节

自顶向下读代码：向下规则

我们想要让代码拥有自顶向下的阅读顺序。我们想要让每个函数后面都跟着位于下一个抽象层级的函数，这样以来，在查看函数列表时，就能循环抽象层级向下阅读了

4.switch语句

写出短小的switch语句很难，写出只做一件事的switch语句也很难，它天生就要做N件事。我们无法避开switch语句，不过还是可以确保每个switch都放在较低的抽象层级，而且永远不重复

根据雇员类型计算薪资：


public Money calculatePay(Employee e) throws InvalidEmployeeType{
    switch (e.type){
        case COMMISSIONED:
            return calculateCommissionedPay(e);
        case HOURLY:
            return calculateHourlyPay(e);
        case SALARIED:
            return calculateSalariedPay(e);
        default:
            throw new InvalidEmployeeType(e.type);
    }
}

这里仅仅依赖了雇员类型一种操作，就有好几个问题了：

函数太长，当有新的雇员类型，还会更长
违反开闭原则，每添加新类型，就必须修改它
违反了单一权责原则，它做了多件事情
更麻烦的是：
到处都有类似的调用函数，比如可能多处调用
isPayday(Employee e, Date date);
或
deliverPay(Employee e, Money pay);

对每个类都会有同样的操作，比如isPayday(), deliverPay()等，不如把类的行为抽象出来到一个抽象类Employee中。在抽象工厂中使用switch语句为Employee的派生物创建适当的实体。

对于switch语句，我们的规矩是如果只出现一次，用于创建多态对象，而且隐藏在某个继承关系中，在其他系统看不到，就还能容忍。当然也要就事论事。


public abstract class Employee{
    public abstract boolean isPayday();
    public abstract Money calculatePay();
    public abstract void deliverPay(Money pay);
}


public interface EmployeeFactory{
    public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType;
}


public class EmployeeFactoryImpl implements EmployeeFactory{
    public Employee makeEmployee(EmployeeRecord r) throws InvalidEmployeeType{
        switch (r.type){
            case COMMISSIONED:
                return new CommissionedEmployee(r);
            case HOURLY:
                return new HourlyEmployee(r);
            case SALARIED:
                return new SalariedEmployee(r);
            default:
                throw new InvalidEmployeeType(r.type);
        }
    }
}

可以想象，用优化后的代码，再有新的类型加入时，业务程序是不用修改的，因为类型已隐藏在了抽象类中，返回给业务的都是抽象的Employee，无需考虑类型的变化，只是调用抽象类的方法即可。我们需要改动的只是再创建一个抽象类的实体类，在EmployeeFactoryImpl中多加一个switch分支。