一、Factory模式
工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。
1.1分类：
工厂模式可以分为三类：
（1）简单工厂模式（Simple Factory)
（2）工厂方法模式（Factory Method)
（3）抽象工厂模式（Abstract Factory）
这三种模式从上到下逐步抽象，并且更具一般性。
GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。
1.2 区别：
（1）工厂方法模式：
一个抽象产品类，可以派生出多个具体产品类。
一个抽象工厂类，可以派生出多个具体工厂类。
每个具体工厂类只能创建一个具体产品类的实例。
（2）抽象工厂模式：
多个抽象产品类，每个抽象产品类可以派生出多个具体产品类。
一个抽象工厂类，可以派生出多个具体工厂类。
每个具体工厂类可以创建多个具体产品类的实例。
工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。
工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以创建多个。
两者皆可。
二、简单工厂模式
简单工厂模式又称静态工厂方法模式。从命名上就可以看出这个模式很简单，它存在的目的，
定义一个用于创建对象的接口。主要用于创建对象，新添加类时，不会影响以前的系统代码。核
心思想是用一个工厂根据输入的条件产生不同的类，然后根据不同类的virtual函数得到不同的结
果。
把创建宝马的操作细节都放到了工厂里面去,客户直接使用工厂的创建工厂方法,传入想要的宝马车型号就行了,而不必去知道创建的细节。即我们建立一个工厂类方法来制造新的对象。如图：
下面我们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式。当客户不再满足现有的车型号的时候，想要一种速度快的新型车，只要这种车符合抽象产品制定的合同，那么只要通知工厂类知道就可以被客户使用了。所以对产品部分来说，它是符合开闭原则的；但是工厂部分好像不太理想，因为每增加一种新型车，都要在工厂类中增加相应的创建业务逻辑（createBMW($type)方法需要新增case），这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类，我们称它为全能类 或者上帝类。
我们举的例子是最简单的情况，而在实际应用中，很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品，所以这可能会把我们的上帝累坏了，也累坏了我们这些程序员:(
于是工厂方法模式作为救世主出现了。 工厂类定义成了接口,而每新增的车种类型,就增加该车种类型对应工厂类的实现,这样工厂的设计就可以扩展了,而不必去修改原来的代码。
三、工厂方法模式
工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承，这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。
工厂方法模式组成：
（1）抽象工厂角色：这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。
（2）具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用创建对应的具体产品的对象。
（3）抽象产品角色：它是具体产品继承的父类或者是实现的接口。
（4）具体产品角色：具体工厂角色所创建的对象就是此角色的实例。
工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；而且这样使得结构变得灵活起来--当有新的产品产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就可以被客户使用，而不必去修改任何已有的代码。可以看出工厂角色的结构也是符合开闭原则的！
可以看出工厂方法的加入，使得对象的数量成倍增长。当产品种类非常多时，会出现大量的与之对应的工厂对象，这不是我们所希望的。因为如果不能避免这种情况，可以考虑使用简单工厂与工厂方法模式相结合的方式来减少工厂类：即对于产品树上类似的种类（一般是树的叶子中互为兄弟的）使用简单工厂模式来实现。
工厂方法小结：
工厂方法模式仿佛已经很完美的对对象的创建进行了包装，使得客户程序中仅仅处理抽象产品角色提供的接口。那我们是否一定要在代码中遍布工厂呢？大可不必。也许在下面情况下可以考虑使用工厂方法模式：
（1）当客户程序不需要知道要使用对象的创建过程。
（2）客户程序使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。
简单工厂模式与工厂方法模式真正的避免了代码的改动了？没有。在简单工厂模式中，新产品的加入要修改工厂角色中的判断语句；而在工厂方法模式中，要么将判 断逻辑留在抽象工厂角色中，要么在客户程序中将具体工厂角色写死（就象上面的例子一样）。而且产品对象创建条件的改变必然会引起工厂角色的修改。
面对这种情况，我们可以使用反射机制：
classCustomer{
private$BMW;
functiongetBMW($type){
$class =newReflectionClass('FactoryBWM'.$type );//建立 'FactoryBWM'这个类的反射类
$instance = $class->newInstanceArgs();//相当于实例化'FactoryBWM' .$type类
return$instance->createBMW();
//或者直接
/**
* $instance = new 'FactoryBWM' .$type();
* return $instance->createBMW();
*/
}
}
四、抽象工厂
随着客户的要求越来越高，宝马车需要配置空调。于是这个工厂开始生产宝马车和配置需要的空调。这时候工厂有二个系列的产品:宝马车和空调.宝马车必须使用对应的空调才能使用.这时候分别使用一个车工厂和一个空调工厂都不能满足我们的需求,我们必须确认车跟空调的对应关系。因此把车工厂跟空调工厂联系在一起。因此出现了抽象工厂模式。
可以说，抽象工厂模式和工厂方法模式的区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。
抽象工厂模式的用意为：给客户端提供一个接口，可以创建多个产品族中的产品对象，而且使用抽象 工厂模式还要满足一下条件：
（1）系统中有多个产品族，而系统一次只可能消费其中一族产品。
（2）同属于同一个产品族的产品以其使用。
抽象工厂模式的各个角色（和工厂方法一样）：
（1）抽象工厂角色：这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。
（2）具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
（3）抽象产品角色：它是具体产品继承的父类或者是实现的接口。
（4）具体产品角色：具体工厂角色所创建的对象就是此角色的实例。
其结构如下：
具体例子：
AbstractFactory 模式关键就是将这一组对象的创建封装到一个用于创建对象的类，维护这样一个创建类总比维护 n 多相关对象的创建过程要简单的多。