简单工厂模式&策略模式

从一系列同类的对象/算法/规则中抽象出共性-基类，客户和基类打交道，问题是如何选择实例化哪个派生类，简单工厂模式中，使用工厂类实例化派生类，选择 过程被封装在工厂类中，客户需要指定一个参数给工厂，工厂按照参数选择实例化出客户需要的派生类。简单工厂模式缺点是：当具体的算法需要改变增加时，就要 修改工厂类，当这种改变的需求很频繁时，工厂方法就比较麻烦了。在简单工厂模式中，客户需要知道抽象基类，也需要知道工厂类；使用工厂类生成对象，使用抽 象基类的接口完成工作。

策略模式(Strategy)定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会 影响到使用算法的客户。策略模式中，除了有一个策略基类以及若干的具体策略（Strategy）类，还有一个上下文(Context)类，Context 类用一个具体的Strategy类来配置，Context类维护对这个Strategy对象的引用。Context类暴露了客户使用的接口，接口通过使用 其引用的策略类的算法接口来实现。为了解决如何选择策略实例化具体算法类的问题，策略模式要和简单工厂模式结合起来。可以通过在构造Context类时指 定参数，来让Context类选择实例化并维护一个策略类，这样客户只和Context类打交道。策略模式在客户端实例化的是Context对象，调用的 是Context类的接口，将策略(即算法)和客户端彻底分离。客户端只需要知道Context类就行了，耦合比简单工厂模式更加降低。（我的理解：其实 又增加了一个间接层Context，Context不但负责选择和实例化-工厂方法，也可以切换策略，比如重新构造新算法实例，从一个全局算法实例组中选 择一个算法等等，实现方法很多）

策略模式的Strategy类层次为Context定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。策略模式还简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。

使用工厂方法的策略模式中，仍然需要通过选择分支来决定需要构造什么算法，当修改或增加算法时，需要修改Context类。