策略模式优化大量if-else

在代码编写的个过程中难免会碰到使用到if-else的情况，太多的if-else会使代码变的臃肿并且难以理解，然后想到了之前写策略模式是可以对它进行优化的，代码的规范和易懂性我认为对一个优秀程序员来说是必要的。

平常经常碰到的代码：

   /**
     * @author : cjd
     * @description : 使用if...else臃肿的代码
     * @return :void
     * @date : 10:07 2018/12/17
     */
    @org.junit.Test
    public void test1() {
        String color = "black";
        if ("black".equals(color)) {
            System.out.println("我是黑色");
        } else if ("blue".equals(color)) {
            System.out.println("我是蓝色");
        } else if ("red".equals(color)) {
            System.out.println("我是红色");
        }
    }

这种情况下如果只是少数并且镶套不多的代码还可以容易理解，但是每当要添加新的else，代码就会变得臃肿并且要修改已有的代码，这就违背了对修改关闭对扩展开放的设计原则，这种情况下就引出了策略模式。

参考

https://blog.csdn.net/chijiandi/article/details/78949373

那么如何修改代码使if-else减少呢？
我们可以把每一段else中的语句当做是一个方法。
为每一个要拿来做判断的条件建一个类来实现一个方法。

为了使扩展开放，我们将方法抽象为接口，并让类实现

   interface Color {
        void doSomeThing();
    }

   /**
     * @author : cjd
     * @description : 将if中的具体实现放入接口实现类中
     * @date : 10:22 2018/12/17
     */
    class Black implements Color {
        @Override
        public void doSomeThing() {
            System.out.println("我是黑色");
        }
    }
    class Red implements Color {
        @Override
        public void doSomeThing() {
            System.out.println("我是红色");
        }
    }

并定义一个策略类来调用方法

 /**
     * @author : cjd
     * @description : 策略模式,根据传入的类判断执行的方法
     * @date : 10:22 2018/12/17
     */
    class ColorStrategy {
        Color color;

        ColorStrategy(Color color) {
            this.color = color;
        }

        void getColor() {
            color.doSomeThing();
        }
    }

使用策略模式优化后的代码如下

    @org.junit.Test
    public void test2() {
        //如果逻辑简单的话也可以直接用new Black().doSomeThing();
        //循环的话使用List<ColorStrategy> colorList = new ArrayList<>();
        //根据实际情况使用反射
        ColorStrategy colorStrategy = new ColorStrategy(new Black());
        colorStrategy.getColor();
    }

这样一来哪怕以后增加更多的else也只是新建一个类，通过类的增加来维护代码的易懂性，同样通过策略模式也能很好的避免多重镶套的if-else。

当然，除了策略模式也有其他方式可以优化的
参考

https://blog.csdn.net/j16421881/article/details/79967948