今天上班时候又看了三章，讲策略模式/开闭原则/单一职责，感觉把，讲故事的篇幅太多了，而且还设计了一些故事情节，策略模式我没有完全信服，开闭原则也讲的牵强，唉反正暂且看着吧，入个门先。

第一章 代码无错就是优？

1. 实现功能的代码，并不是好的代码

如果我来做，肯定是一个类就完事了，虽然可以实现功能，但是一丁点面向对象的影子都没有，这样写出来的程序不易于维护，新增功能或者修改功能需要整个程序都参与，这样肯定算不上好代码。

这一章里就讲了怎样用封装继承多态，来实现这么一个计算器。

首先定义一个操作抽象类，提供一个抽象方法，获取操作结果，加减乘除都继承整个类。以后如果要增加运算，或者修改某种运算的逻辑，只单独修改那一个运算子类就可以，而不用其他的运算类都参与编译。

/**
 * 操作抽象类
 */
public abstract class Operation {

    public abstract double getResult(double operandA, double operandB);
}

/**
 * 加法运算子类
 */
public class OperationAdd extends Operation {

    @Override
    public double getResult(double operandA, double operandB) {
        return operandA + operandB;
    }

}

---

2. 如何让客户端程序员知道需要生成哪个运算子类？ -- 简单工厂模式

简单工厂模式解决的是如何实例化对象的问题 -- “到底要实例化哪个对象？将来会不会增加实例化的对象？这是很容易发生变化的地方，考虑使用一个单独的类来做这个创造实例的过程，这个单独的类就是工厂。”

通过传入运算符，switch中决定实例化哪个运算子类。

/**
 * 创造运算子类的工厂
 */
public class OperationFactory {

    public static Operation createOperation(String operator) {

        Operation opera = null;

        switch (operator) {

        case "+":
            opera = new OperationAdd();
            break;

        case "-":
            opera = new OperationSub();
            break;

        case "*":
            opera = new OperationMul();
            break;

        case "/":
            opera = new OperationDiv();
            break;

        }

        return opera;
    }
}

这样，以后不管新增运算种类，还是修改已经有的运算类，修改的部分都很小。

书好不好，每个人都有自己的看法，客观也好，偏激也好，对你自身来讲，你能从这本书中获得提升，那对你来说这本书就是好书。
刚看了第一章，计算器这个小小的程序，我之前肯定一个类就解决了，现在发现竟然也可以这样解耦，面向对象来做，真的对自己还是有点影响的。

https://github.com/toyranger/design_patterns_chengjie.git