这两种模式的作用就是拥抱变化，减少耦合。在变化来临时争取做最小的改动来适应变化。这就要求我们把那些“善变”的功能从客户端分离出来，形成一个个的功能类，然后根据多态特性，使得功能类变化的同时，客户端代码不发生变化。
简单工厂模式
简单工厂模式：有一个父类需要做一个运算（其中包含了不同种类的几种运算），将父类涉及此运算的方法都设成虚方法，然后父类派生一些子类，使得每一种不同的运算都对应一个子类。另外有一个工厂类，这个类一般只有一个方法（工厂的生成方法），这个方法的返回值是一个超类，在方法的内部，根据传入参数的不同，分别构造各个不同的子类的对象，并返回。客户端并不认识子类，客户端只认识超类和工厂类。每次客户端需要一中运算时，就把相应的参数传给工厂类，让工厂类构造出相应的子类，然后在客户端用父类接收（这里有一个多态的运用）。客户端很顺理成章地用父类的计算方法（其实这是一个虚方法，并且已经被子类特化过了，其实是调用子类的方法）计算出来结果。如果要增加功能时，你只要再从父类中派生相应功能的子类，然后修改下工厂类就OK了，对于客户端是透明的。
策略模式
策略模式：策略模式更直接了一点，没有用工厂类，而是直接把工厂类的生成方法的代码写到了客户端。客户端自己构造出了具有不同功能的子类（而且是用父类接收的，多态），省掉了工厂类。策略模式定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。这里的算法家族和简单工厂模式里的父类是同一个概念。当不同的行为堆砌在一个类中时，就很难避免使用条件语句来选择合适的行为，将这些行为封装在一个个独立的策略子类中，可以在客户端中消除条件语句。
简单工厂模式+策略模式：为了将工厂方法的代码从客户端移出来，我们把这些代码搬到了父类的构造函数中，让父类在构造的时候，根据参数，自己实现工厂类的作用。这样做的好处就是，在客户端不用再认识工厂类了，客户端只要知道父类一个就OK，进一步隔离了变化，降低了耦合。
在基本的策略模式中，选择所用具体实现的职责由客户端对象成端，并转给客户端。这本身并没有减除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由父类承担，这就最大化地减轻了客户端的职责。