设计模式-策略模式

先来理解生活中的一些现象，在很多生活当中会遇到这样的情况，我们去一个目的地，可以有不同的方式，可以选择火车，汽车， 飞机，也可以选择不同的路线，这些不同的方式也就是不同的策略，在软件开发过程中，也会有一些类似的情况，实现一个功能，可能有很多种途径，为了诞生了策略模式。

来分析一个案例，某电影院开发一个票价系统，而票价每周会有不同的打折方式。例如，10岁以下的孩子，享受减10元的票价优惠，VIP则可以打五折优惠等等。对于这样一个案例，最终的票价可以理解为旅游到达的目的地，而不同的价格打折方式则可以理解为不同的路径策略。

对于以上这种情况正常的写法，就是一个环境类代表电影院，然后方法里面运用if else根据不同的价格判断，采用不同的打折算法。这样的一种设计存在以下几个方面的不足：

第一：这个环境类的责任过于重大，即负责得到电影票的价格类型，也要负责相关算法的实现，造成类非常庞大，不利于维护，也违反了单一职责原则；

第二：如果想扩展一个新的票价价格，则需要更改这个类的方法，违反了开闭原则；

第三：复用性很差，如果某一个价格方法，需要被其他一个系统来用，则需要复制代码，降低的系统的可维护性

为此，利用策略模式来实现以上功能，

编写一个环境类，此类这个类负责得到最终价格和提供什么类型的用户。然后写不同算法实现类。到此之后，问题来了，要再环境来和具体的算法实现类之间，有一个一个关联关系。那么这个关联关系应该怎么设置进去呢？具体采用什么方式来以来，是谁依赖谁呢？分析具体类的职责，环境类功能就是得到最终的价格，因此，可以知道在环境类里面注入不同的算法，是一种合理的设计。但是，以什么方式注入呢？构造注入，设置注入，还是借口注入。在此种情况下，我们应该遵守依赖倒转原则，针对抽象编程，采用接口注入的方式实现对象之间的依赖关系。为了，可以设置不同算法的抽象类，并且针对这个抽象类注入，可以在环境类里面设置方法，传入不同算法实现的抽象类，然后环境类里面调用抽象方法。具体的算法实现类可以配置在XML文件中，默认实现抽象类的抽象方法。这样也增加了系统的可维护性，同时也在策略使用的时候具有一致性。

设计模式的核心，是把软件实现与现实生活相联系，利用这种思维方式，用代码方式实现生活中的现象。多加练习。