设计模式阅读笔记（4）-----------工厂模式

有些开发人员会把简单工厂认为是工厂模式，其实并不是，简单工厂是种习惯。这种做法是将类的实例化任务交予了其他类来实现，避免在代码中用new初始化类。

如图是简单工厂的使用：

这样，User在使用Product的时候不用去new一个相应的Product类型，而是调用ProductFactory的createProduct方法来获得一个Product实例。那这种方法相比我们去使用new来创建实例有什么好处呢？这里要提到一个设计原则，对修改关闭，将容易改变的代码抽离。User的目的是使用Product，那如果当product产生变化，比如新增了一种类型的product的时候，如果我们是在User中使用new新建实例，我们就需要进入User类中对代码进行修改，这样User就没有做到对修改关闭，更加可怕的是增加product的人可能根本不知道有哪些User需要修改。因此简单工厂可以将实例化部分抽出，给User的useProduct方法增加一个productType参数，就可以创建所需要的product。

下面才是工厂方法模式

定义：工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个，工厂方法让类把实例化推迟到了子类。

根据定义我们就可以看出，该模式使用方法来实现了工厂的功能。

为什么会有这种需要呢？或者说，简单工厂有什么不足的地方？我们假设有这种场景，出现了两种类型的用户，他们要使用不同系列的产品，两系列的产品略有不同。在这种情况下，ProductFactory并不能限制产出的产品，UserA,UserB都要改写useProduct来实现功能。这样导致了useProduct方法没能复用，而且本身useProduct的功能就是要执行product的productAction方法而已，不应该关注使用的是哪种产品，根据面向接口原则，这样是不好的。

因为子类才需要决定实例化的类是哪个，所以父类是不需要知道这个的，我们在父类添加了虚函数 createProduct 来代替ProductFactory的功能，注意，父类是不用实现这个方法的，子类才进行实现。createProduct方法返回需要的Product类来使用。

工厂方法模式如图：

其中User和Product类是很多个的，但是画出来会很乱。这样编写的useProduct方法可以复用。User作为子类，必须实现相应的createProduct方法来决定要生成哪些Product。

这里就要提到依赖倒置原则，要依赖抽象，不要依赖具体类。那工厂方法模式哪里体现到了这个原则呢？按我们正常的设计来说，用户要使用各种各样的产品，那么不同用户就会依赖于各种产品。将产品抽象出一个产品接口，那么各种产品就依赖于产品接口，用户也依赖产品接口，这样依赖就倒置了。【这是根据书上总结来的，但是我个人是不怎么理解的】

在这里我产生了疑惑，既然说要针对接口编程而不是针对实现编程，可是我们在User类的createProuct中依然实例化了相应的product，这是不是有问题呢？

抽象工厂模式看上去解决了这种问题，我现在也还没明白这两种的优缺点，不使用抽象工厂而用工厂方法的情况是怎么样的。

按我理解，抽象方法就是讲工厂方法抽取出来，到工厂接口中，再由工厂实现类来决定实例化产品。

入图所示：

其中Product可以是多系列的，如果增加一个系列的话，可以在抽象工厂中添加新的工厂方法。