从上篇文章里面提到了工厂模式，今个就说说这个广泛使用的模式；“工厂模式专门负责将大量有共同接口的类实例化”——闫宏《java 与模式》。
工厂模式分为简单工厂模式、工厂方法模式与抽象工厂模式。
简单工厂模式
简单工厂模式又叫静态工厂模式，是最简单的一种，当然缺点也明显，先看下他的 UML 图
从上图看到，他需要一个产品接口，和一个具体产品，然后工厂就能够根据需要造出对应的实例。
直接上代码，先来个产品接口（为什么要这个东西？坑），当然抽象类也可以，这里用抽象类
public abstract class AbstractPerson {
public AbstractPerson() {
}
}
有了抽象的产品，接着把具体的产品造出来，可以有 n 个，这里简化处理，举一个例子
public class Person1 extends AbstractPerson{
public Person1() {
System.out.println("this is person1");
}
}
好了，有了准备的材料，使用简单工厂的方法，把东西造出来
public class SimpleFactory {
public static AbstractPerson person(int num){
AbstractPerson person=null;
if(num==1){
person=new Person1();
}else if(num==2){
person=new Person2();
}
return person;
}
}
抽象工厂创造的是一个抽象的对象，这就是为什么要有个抽象接口的原因，填了之前的坑。
现实的情况可能比这复杂许多，产品的级联更多，像组织结构一样，这些各种各样的产品，可以使用同一个工厂进行构造，当然，期间可以使用抽象接口进行继承来达到想要的结果，不再赘述。简单工厂使用静态
static方法，使得工厂方法不能够继承，使得工厂等级也无法继承，这个时候工厂方法模式来了。
工厂方法模式
该模式是对简单工厂模式的进一步抽象，工厂本身不干具体的活了，他有几个小弟（继承者）来做具体的工厂工作。UML图如下
来具体看下源码，首先看下抽象工厂，他只和抽象产品打交道
public abstract class AbstractFactory {
public abstract Person getPerson();
}
下面是抽象产品，依然和上面例子一样
public abstract class Person {
public Person() {
}
}
接下来，先把具体的商品，这里就是人给具体制造出来
public class Person1 extends Person {
public Person1() {
System.out.println("Person1");
}
}
public class Person2 extends Person {
public Person2() {
System.out.println("Person2");
}
}
两个人被构造出来了，接下来看下2个具体工厂
public class Person1Factory extends AbstractFactory{
@Override
public Person getPerson() {
return new Person1();
}
}
public class Person2Factory extends AbstractFactory{
@Override
public Person getPerson() {
return new Person2();
}
}
好，这下具体工厂都构造好，具体人也构造好，怎么使用呢？看下客户端吧
public class Main {
public static void main(String[] args) {
AbstractFactory factory=new Person1Factory();
Person person1 = factory.getPerson();
factory=new Person2Factory();
Person person2 = factory.getPerson();
}
}
这里的意思就是需要什么人（产品），就到什么工厂去拿。这就对原来简单工厂进行了扩展，使得抽象工厂能够扩展 n 多具体工厂，而原来简单工厂核心是在一个具体类上。缺点是会造成工厂成堆。
抽象工厂
针对产品簇，该模式有独到之处，该模式 UML 图如下
抽象产品不再是一个，抽象工厂还是和上一个一样，在具体的工厂里面所做的事也有所区别。
这里代码我们采用传统的汽车构造来演示，虽然讨厌汽车这种奔死器的东西，汽车包括引擎和轮子等，为了简化，就造这两个东西，引擎有日系引擎和德系引擎，轮子同样有锦湖轮，有回力的等，先把抽象的造好，为了扩展。
public abstract class Engine {
}
public abstract class Wheel {
}
两个抽象产品出来了，啥事也没干。再把抽象工厂也弄出来
public interface Factory {
Engine createEngine();
Wheel createWheel();
}
抽象工厂像个领导一样，象征性的做了点工作，其实也是啥也没干。那么还是把实际干事的请出来吧。
//引擎部分
public class EngineA extends Engine{
public EngineA() {
System.out.println("创建日系引擎");
}
}
public class EngineB extends Engine{
public EngineB() {
System.out.println("创建德系引擎");
}
}
//车轮部分
public class WheelA extends Wheel{
public WheelA() {
System.out.println("造锦湖轮胎轮子");
}
}
public class WheelB extends Wheel{
public WheelB() {
System.out.println("造回力牌子轮子");
}
}
好了，各个部件都做好了，具体工厂像个总工程师一样，向大伙发号施令进行组装，这里有2个具体工厂
public class FactoryA implements Factory{
@Override
public Engine createEngine() {
return new EngineA();
}
@Override
public Wheel createWheel() {
return new WheelA();
}
}
public class FactoryB implements Factory{
@Override
public Engine createEngine() {
return new EngineB();
}
@Override
public Wheel createWheel() {
return new WheelB();
}
}
好了，具体工厂组装完毕，我们需要的零件都好了，我们的客户端就和这些工厂打交道，不和具体生成产品的分包商打交道，工厂是总包。
public class Main {
public static void main(String[] args) {
//从第一个工厂买辆车
Factory f=new FactoryA();
f.createEngine();
f.createWheel();
//从另外个工厂买辆车，有钱任性
f=new FactoryB();
f.createEngine();
f.createWheel();
}
}
到此为止，工厂模式告一段落，工厂模式用的地方很多，尤其是在构造级联对象的时候，需要考虑下工厂模式。所有的依赖都是依赖抽象，为什么呢？举个例子吧。
能骑白马，可以说此人能骑马，能骑黑马也可以说是能骑马，这里就是把马作为依赖来说，白马黑马都是马的继承；反过来不一定；而如果把具体作为依赖呢，是这样子的，有个美女类，有个妹妹是美女的一种，哥哥喜欢这个妹妹，不能说哥哥喜欢美女，哥哥喜欢妹妹就是哥哥依赖具体的妹妹，不能上升到哥哥喜欢美女这个层面。——来自闫宏的《java与模式》的白话版
