如何在代码中应用设计模式？

做者：宁愿呢
https://www.cnblogs.com/liyus...

为何要使用设计模式

由于咱们的项目的需求是永远在变的，为了应对这种变化，使得咱们的代码可以轻易的实现解耦和拓展。若是可以保证代码一次写好之后都不会再改变了，那能够想怎么写怎么写了。

如何判断那里须要使用设计模式

在咱们实现中，有一些代码是一次写好后续基本不会改变的，或者不太须要扩展的，好比一些工具类等。有一部分是会常常变得，设计模式大多都应用在需求会变化的这一部分。分析这些代码会如何变，选择合适的设计模式来优化这部分代码。

以促销活动需求为例

需求

为了促进商品的销售，各大电商品台会在平时或者一些节日的时候退出一些促销活动刺激用户消费，活动的类型可能会各不相同，以下：

• 满减，满400减20
• 代金卷，玛莎拉蒂5元代金卷
• 折扣，9折，8折
• 每满减，每满200减10
• 等等

其中有些能够叠加，有些只能单独使用。

简单实现

上面的需求看起来仍是比较简单的，可是若是考虑到咱们是不可能一次定义好全部的促销活动类型，后续咱们可能会随时都添加新的类型，要保证可以简单的实现功能扩展，那就比较麻烦了。Spring 框架用到的 9 个设计模式汇总，这个你知道吗？

先拿到需求的时候，也不用去想那么多，挽起袖子就是一通操做：

public class OrderPromotion {  
  
    public BigDecimal promotion(Order order, int[] promotions){  
        for(int promotion:promotions){  
            switch (promotion){  
                case 1:  
                    //计算该类型折扣后的价格  
                    break;  
                case 2:  
                    //计算该类型折扣后的价格  
                    break;  
                case 3:  
                    //计算该类型折扣后的价格  
                    break;  
                //....  
            }  
        }  
        return order.getResultPrice();  
    }  
}

单从功能实现上来讲，上面的代码已经完成了基本功能了。

可是上面的代码也是致命的，虽然看起来很简单，可是那只不过是由于大多数功能都用注释代替了，换成实际代码的话一个方法可能就得上千行。

尤为是当咱们须要添加新的促销活动的话就须要在switch中添加新的类型，这对于开发来讲简直是灾难，而且维护这些代码也是一个麻烦。

优化一：单一职责原则

上面的代码中，promotion(…)方法直接完成了全部的工做，可是咋咱们实际实现中最好让一个方法的职责单一，只完成某一个功能，因此这里咱们将对折扣类型的判断和计算价格分开：

public class OrderPromotion {  
  
    public BigDecimal promotion(Order order, int[] promotions){  
        for(int promotion:promotions){  
            switch (promotion){  
                case 1:  
                    calculate1(order);  
                    break;  
                case 2:  
                    calculate2(order);  
                    break;  
                case 3:  
                    calculate3(order);  
                    break;  
                //more promotion  
            }  
        }  
        return order.getResultPrice();  
    }  
  
    public void calculate1(Order order){  
        //计算使用折扣一后的价格  
    }  
  
    public void calculate2(Order order){  
        //计算使用折扣二后的价格  
    }  
  
    public void calculate3(Order order){  
        //计算使用折扣三后的价格  
    }  
  
    //more calculate  
  
}

这里咱们将折扣类型的判断和计算价格分开，使得promotion(…)方法的代码量大大下降，提高了代码的可读性。面象对象设计6大原则之一：单一职责原则，这篇也推荐你们看下。

优化二：策略模式

上面优化后的代码提高了原有代码的可读性，可是原来OrderPromotion类代码大爆炸的问题仍是没有解决。

针对这个问题，咱们但愿可以将计算的代码和当前代码分离开，首先咱们能想到的就是定义一个类，而后将计算的代码复制到这个类中，须要的时候就调用。这样到的确是分离开了，可是彻底是治标不治本。在添加新的促销活动是两个类都要改。

因此咱们但愿可以将不一样的促销活动的实现分离开，这样对每一种活动的实现都是分开的，修改也不会影响其余的，基于此咱们彻底能够选择策略模式来实现。

策略模式

策略模式的思想是针对一组算法，将每一种算法都封装到具备共同接口的独立的类中，从而是它们能够相互替换。策略模式的最大特色是使得算法能够在不影响客户端的状况下发生变化，从而改变不一样的功能。

public class OrderPromotion {  
  
    public BigDecimal promotion(Order order, int[] promotions){  
        for(int promotion:promotions){  
            switch (promotion){  
                case 1:  
                    new PromotionType1Calculate(order);  
                    break;  
                case 2:  
                    new PromotionType1Calculate(order);  
                    break;  
                case 3:  
                    new PromotionType1Calculate(order);  
                    break;  
                //more promotion  
            }  
        }  
        return order.getResultPrice();  
    }  
}

上面的代码很明显已经精简不少了，到了如今若是须要添加一个促销活动的话只需定义一个促销类，实现PromotionCalculation接口而后在switch中添加便可。

优化三：工厂模式

上面的代码虽然已经将促销活动的实现分离开了，可是OrderPromotion仍是一直在变得，每一次添加或者下线活动都须要修改该类。

如今咱们但愿OrderPromotion是不变的，将PromotionCalculation的实例化剥离开来。建立类很明显是使用工厂设计模式了。

OrderPromotion

public class OrderPromotion {  
  
    public BigDecimal promotion(Order order, int[] promotions){  
        for(int promotion:promotions){  
            PromotionFactory.getPromotionCalculate(promotion).calculate(order);  
        }  
        return order.getResultPrice();  
    }  
}

类的建立工做交给工厂来实现。

PromotionFactory

public class PromotionFactory {  
  
    public static PromotionCalculate getPromotionCalculate(int promotion){  
        switch (promotion){  
            case 1:  
                return new PromotionType1Calculate(order);  
            break;  
            case 2:  
                return new PromotionType1Calculate(order);  
            break;  
            case 3:  
                return new PromotionType1Calculate(order);  
            break;  
            //more promotion  
        }  
        return null;  
    }  
}

使用工厂模式后OrderPromotion类就不须要改了，每一次添加新的促销活动后只须要在工厂类中添加便可。

优化四：配置+反射

上面的代码还存在的问题在于每一次须要添加新的促销活动的时候仍是须要修改工厂类中的代码，这里咱们经过配置文件加反射的方式来解决。

定义映射配置文件

mapping.properties

1=design.order.PromotionType1Calculate  
2=design.order.PromotionType2Calculate  
3=design.order.PromotionType3Calculate

PromotionFactory

public class PromotionFactory {  
  
    private static Map<Integer, String> mapping = new HashMap<Integer, String>();  
  
    static {  
        try {  
            Properties pps = new Properties();  
            pps.load(new FileInputStream("Test.properties"));  
            Iterator<String> iterator = pps.stringPropertyNames().iterator();  
            while(iterator.hasNext()){  
                String key=iterator.next();  
                mapping.put(Integer.valueOf(key), pps.getProperty(key));  
            }  
        } catch (IOException e) {  
            e.printStackTrace();  
        }  
    }  
  
    public static PromotionCalculate getPromotionCalculate(int promotion) throws Exception {  
        if(mapping.containsKey(promotion)){  
            String beanName = mapping.get(promotion);  
            return Class.forName(beanName).newInstance();  
        }  
        return null;  
    }  
}

经过上面的代码就能够实现不改变已有代码的前提下实现对功能的灵活扩展。固然，这里的代码只是做为演示用的，实际上能够改进的地方还有很多，像最后反射效率较低，也能够经过其余的方式来实现。

小结

设计模式是咱们必定要了解的东西，熟悉设计模式能让咱们设计出易于扩展和维护的代码结构。可是并非任何地方都须要上设计模式，应该结合咱们的项目实际进行分析是否须要设计模式，使用哪一种设计模式。

推荐去个人博客阅读更多：

1.Java JVM、集合、多线程、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、后端、架构、阿里巴巴等大厂最新面试题

生活很美好，明天见～