从简易计算器到设计模式（策略、简单工厂）

前言

最近在拜读《大话设计模式》这本书，作为一个小白中的小白，读完以后感触还是很深的。再次做一个学习的记录，同时也算给自己多一次实践的机会。

问题

相信大家在上学时都写过“简易计算器”，就是要求很简单的键盘输入两个数字，然后再给定一个符号，去做加减乘除运算。最简单的计算器实现，实在是大学老师最爱的练习小demo之一呢hhhh

V1.0版本

大家思路都差不多，这不是直接一个switch就解决了吗？这不是有手就行？立马感觉自己能进BAT了呢hhhh（瞎掰的）

public static void main(String[] args) {
        //假装这是用户输入的东西
        Double num = null;
        Double otherNum = null;
        String operator = "*";
        Double result = null;

        //使用switch进行比对
        switch (operator){
            case "+":
                result = num+otherNum;
                break;
            case "-":
                result = num-otherNum;
                break;
            case "*":
                result = num*otherNum;
                break;
            case "/":
                //判断被除数不能为0
                if (otherNum != 0){
                   result = num/otherNum; 
                }
                break;
        }
    }

这样写就存在两个问题。

1.如果用户输出的是"/"，那么前三次对比就相当于做了无用功，虽然在这种微乎其微的程序上没影响，但是一旦数量多了起来那就难以想象了。

2.从面向对象的设计原则上说，其实有违开闭原则。

开闭原则：对扩展开放，对修改封闭

以上述例子来说就是，允许增加新的计算方式，比如增加取余运算。但是原则上不允许修改原有的计算方式（加减乘除）！当然也不会有人有病去瞎改hhh，但是指不定手滑呢，就可能会导致原有的代码运行出问题。

于是2.0版本就应运而生！

V2.0版本

脑子一转，那可以考虑工具类。将业务逻辑部分进行封装。这样就遵循开闭原则了吧，至少是部分遵守了hhhh

public class OperationUtils {

    public static Double GetResult(double num,double otherNum,String operator){
        Double result = null;
        switch (operator){
            case "+":
                result = num+otherNum;
                break;
            case "-":
                result = num-otherNum;
                break;
            case "*":
                result = num*otherNum;
                break;
            case "/":
                //判断被除数不能为0
                if (otherNum != 0){
                    result = num/otherNum;
                }
                break;
        }
        return result;
    }
}

但是这也只是仅仅达到了封装的目的，如果按照我们以上的设想，当我们需要增加运算方式时，其实还是要去修改工具类里的东西，所以根本上还是没有遵守开闭原则。

于是v3.0版本应运而生..........

V3.0版本

首先设计一个计算的接口，其中只有一个得到计算结果的方法。至于如何实现，就根据不同实现类的计算方式即可。

计算操作接口

public interface Operation {
    /**
     * 计算结果的方法
     * @param num
     * @param otherNum
     * @return
     */
    Double getResult(double num,double otherNum);
}

加法实现类

/**
 * 加法实现类
 */
public class AddOperation implements Operation{
    //重写加法的计算方法
    @Override
    public Double getResult(double num, double otherNum) {
        Double result = null;
        result = num + otherNum;
        return result;
    }
}

减法实现类

/**
 * 减法实现类
 */
public class SubOperation implements Operation {
    //重写减法的计算方法
    @Override
    public Double getResult(double num, double otherNum) {
        Double result = null;
        result = num - otherNum;
        return result;
    }
}

剩余的实现类相信各位大佬肯定知道咋写了吧，这里本人就不一一展示了，就当给各位练练手吧（有懒狗，我不说是谁）

主函数

 public static void main(String[] args) {
            //假装这是用户输入的东西
            Double num = null;
            Double otherNum = null;
            String operator = "*";
            Double result = null;
            //加法实现
            AddOperation addOperation = new AddOperation();
            result = addOperation.getResult(num,otherNum);
            //减法实现
            SubOperation subOperation = new SubOperation();
            result = subOperation.getResult(num,otherNum);
}

至此，看起来就比较符合开闭原则了。

如果还需要增加计算方式，只需要实现计算方法接口即可。在增加时，因为根本不是同一个实现类，也就不要担心手滑碰到原有的代码从而导致被老板开除hhhh。

扩展知识点：面向接口编程

这也就是大家常说的面向接口编程，可以通俗理解为只将方法暴露在外，实际实现的逻辑其实在不同的实现类中。面向接口编程最早的体现（针对我来说）——为啥在三层架构中，业务逻辑层为啥要弄个Interface，然后又要搞个实现类去重写方法。这不是脱裤子放屁吗？我直接写我需要的方法不就好了。

现在想想当初的自己还是天真了hhhh，不得不感叹面向对象的博大精深啊...

策略模式

另外诸如此类的实现方法，也体现了设计模式的策略模式。

通俗理解：将不同的算法（加法，减法，乘法，除法）进行封装，这就可以让不同的地方使用相同的算法。也就是我那一天心血来潮新写了计算器plus，我就不用再把加减乘除的方法重新写一遍，直接把之前封装好的拿过来用就好了。（这样也避免了大量分支判断的存在，导致整个代码显得非常臃肿并且后期难以维护和修改）

因为本小弟也是初学者，理解得可能不是很透彻，有兴趣的hxd往这走

有趣的设计模式——解救抓狂的商场收银员

V4.0版本

以为3.0就完结了？必定不可能！其实在计算方面确实做的差不多了（以我的能力而言），4.0更多的是针对现有代码基础的优化。

我们虽然写了不同的计算实现类，但是在每次需要使用的时候，都要new一个对应实现类的对象，然后再调用getResult()方法进行计算。这样计算的东西少一点还好，要是用户加减乘除挨个来一遍，再倒着来一遍，那岂不是new对象都要花费很多时间？？？

简单工厂模式

通俗理解：我们需要一个各种实现类的集中制造基地，我们只要告诉工厂我要加法或者减法，它就直接给我们即可，不需要我们繁琐的自己去new一个新的对象。

简单计算实现类工厂

public class OperationFactory {
    /**
     * 获取实现类对象方法
     * @param operator
     * @return
     */
    public static Operation createOperation(String operator){
        Operation operation = null;
        //看运算符来判断需要生成的实现类
        switch (operator){
            case "+":
                operation = new AddOperation();
                break;
            case "-":
                operation = new SubOperation();
                break;
            case "*":
                operation = new MultiplicaOperation();
                break;
            case "/":
                operation = new DivOperation();
                break;
        }
        return operation;
    }
}

 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------更新于2022.09.26----------------------------------------------------------

简单工厂模式PRO

最近看到一个新的写法，就此记录下。首先我们分析下现有的简单工厂，主要存在两个问题。

1.代码入侵性比较强，每次在添加新的“计算方法”的时候，都要在OperationFactory类中进行新增，其实是有违开闭原则的。

2.多分支的判断，导致做了很多无用功。比如说：当前需要除法，但是必须case到最后一个分支才能得到，也就是前三次对比其实是无用功。

那么我们考虑通过反射来进行代码的优化

思路：通过反射直接进行对象的实例化

创建一个相关配置文件，后期更加方便修改。其中存对应的包名。

 更改简单工厂类

public class OperationFactory {

    public static Operation createOperation(String name){
        //首先读取配置文件，获取对应包名
        Properties properties = new Properties();
        Class<?> cls = null;
        Operation operation = null;
        try {
            //读取配置文件
            properties.load(new FileInputStream("src/main/resources/name.properties"));
            //获取包名
            String className = properties.getProperty(name);
            //通过反射实例化对象
            cls = Class.forName(className);
            operation = (Operation) cls.newInstance();
        }catch (Exception e){
            System.out.println("处理异常...");
        }
        return operation;
    }
}

测试类

public class Test {

        public static void main(String[] args) {
            //假装这是用户输入的东西
            Double num = 10.5;
            Double otherNum = 2.5;
            Double result = null;
            //加法实现
            Operation addOperation = OperationFactory.createOperation("Add");
            result = addOperation.getResult(num,otherNum);
            System.out.println("加法计算结果:"+result);
            //减法实现
            Operation subOperation = OperationFactory.createOperation("Sub");
            result = subOperation.getResult(num,otherNum);
            System.out.println("减法计算结果:"+result);
    }
}

 结果展示

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------更新于2022.09.27-----------------------------------------------------

工厂方法模式

昨天的我无法理解工厂方法模式，今天的我突然茅塞顿开，再次记录一下。

何为工厂方法模式？和简单工厂的区别是什么？

工厂方法模式是对简单工厂的再一次抽象，克服了简单工厂的一些缺点。

举个栗子来说

=========================================================================

简单工厂模式：一个手机工厂同时造安卓手机（对象）和水果手机（对象）

工厂方法模式：手机工厂分为安卓手机厂（工厂）和水果手机厂（工厂），安卓手机厂只造安卓手机，水果厂只造水果手机

=========================================================================

书接上文，直接上代码。

1.首先准备一个公共工厂接口，需要实现创建实例的方法

public interface Factory {

    Operation createOperation();
}

2.加法工厂的实现，通过实现工厂接口从而重写方法

public class AddOperationFactory implements Factory{
    @Override
    public Operation createOperation() {
        AddOperation addOperation = new AddOperation();
        return addOperation;
    }
}

减法工厂，乘法工厂，除法工厂以此类推，就不（有）演（懒）示（狗）了。

小结（简单工厂和工厂方法的区别）

1.简单工厂其实是违背开闭原则的，因为每次新增创建实例的判断，其实都需要在原来的地方进行修改。而工厂方法只是实现接口，也就是不会修改原有的代码，只是做新增。

2.简单工厂将创建什么的实例（加法还是减法）的逻辑判断放在了内部，而工厂方法其实把这个判断移到了客户端进行，只有在创建时由客户端进行判断。

示例：

简单工厂测试类

public class Test {

        public static void main(String[] args) {
            //假装这是用户输入的东西
            Double num = 10.5;
            Double otherNum = 2.5;
            Double result = null;
            //加法实现
            //用户只负责讲运算符传入，具体实例哪个对象在内部进行判断
            Operation addOperation = OperationFactory.createOperation("Add");
            result = addOperation.getResult(num,otherNum);
            System.out.println("加法计算结果:"+result);
          
    }
}

工厂方法测试类

public class Test {

        public static void main(String[] args) {
            //假装这是用户输入的东西
            Double num = 10.5;
            Double otherNum = 2.5;
            Double result = null;
            //在客户端时，就知道需要创建的是加法工厂，而不是在内部进行判断
            Factory factory = new AddOperationFactory();
            Operation addOperation = factory.createOperation();
            result = addOperation.getResult(num,otherNum);
    }
}

工厂方法模式后续优化同样可以考虑由反射进行实例创建，这里留个坑过后补上。

任何设计模式没有绝对的好与坏，只看那种情况下的适配性最好，什么时候是最佳选择！

总结

至此真的完结了，仅仅看了第一小节，感觉腰不疼了，腿不酸了呢，实乃上古神书之一！

以上纯属瞎掰。

分享书中一句话：编程是一门技术，更是一门艺术。

曾经我就很好奇，大家都是流水线式的逻辑进行业务的实现，这还能分出好坏？现在看来实在是当初自己太年轻了hhh。

如有问题，请各位大佬指正。-----记一个菜狗的学习记录