工厂方法模式

 

简单工厂 VS 工厂方法

 

简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。例如计算器，让客户端不用管该用哪个类的实例，只需要把“+”给工厂，工厂自动就给出了相应的实例，客户端只要去做运算就可以了，不同的实力会实现不同的运算。但问题也就在这里，如果要加一个“求M的N次方”的功能，我们是第一需要给运算工厂类的方法里加一个分值条件，修改原有的类？？这可不是好办法，这就等于说，我们不但对扩展开放了，对修改也开放了，这样就违背了开放-封闭原则。

 

工厂方法模式（Factory Method），定义一个用户创建对象的接口，让子类决定实例化那一个类。工厂方法是一个类的实例化延迟到其子类。

 

 

既然这个工厂类与分支耦合，那么我就对他下手，柑橘以来倒转原则，我们把工厂类抽象出一个接口，这个接口只有一个方法，就是创建抽象产品的工厂方法。然后，所有要产生具体类的工厂，就去实现这个接口，这样，一个简单工厂模式的工厂类，变成了一个工厂抽象接口和多个具体生成对象的工厂。

 

 

工厂方法模式实现时，客户端需要决定实例化那个一工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。你想要加功能，本来是改工厂类的，而现在是修改客户端。