工厂模式的目的就是将对象的创建过程隐藏起来，从而达到很高的灵活性，工厂模式分为三类：

• 简单工厂模式
• 工厂方法模式
• 抽象工厂模式

在没有工厂模式的时候就是，客户需要一辆马车，需要客户亲自去创建一辆马车，然后拿来用。

• 在简单工厂模式下，客户可以通过工厂获得一辆马车，需要下单后，告诉马车的型号，然后工厂可以根据型号创建马车。
• 在工厂方法模式下：客户想要一辆马车，需要指明型号创建。比如325i的bmw,和530li,根据各自325i的工厂和530li的工厂创建，每个工厂创建一个系列。即具体的工厂只能创建出一个具体的产品。
• 在抽象工厂模式下：客户想要一辆带空调的宝马车，于是开始创建带空调的宝马车，不需要自己创建安装。

不适用工厂模式

如果不使用工厂，用户将自己创建宝马车，具体UML图和代码如下：

public class BMW320 {
    public BMW320(){
        System.out.println("制造-->BMW320");
    }
}
 
public class BMW523 {
    public BMW523(){
        System.out.println("制造-->BMW523");
    }
}
 
public class Customer {
    public static void main(String[] args) {
        BMW320 bmw320 = new BMW320();
        BMW523 bmw523 = new BMW523();
    }
}

用户需要知道怎么创建一款车，这样子客户和车就紧密耦合在一起了，为了降低耦合，就出现了简单工厂模式，把创建宝马的操作细节都放到了工厂里，而客户直接使用工厂的创建方法，传入想要的宝马车型号就行了，而不必去知道创建的细节。

简单工厂模式：

核心是：创建一个对象的接口，然后根据接口创建具体的实现，将创建与本身的业务逻辑分开，降低耦合度。

1.UML图：

• 工厂类角色： 该模式的核心，用来创建产品，含有一定的商业逻辑和判断逻辑

• 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。

• 具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。

2.代码实现：

产品类

abstract class BMW {
	public BMW(){}
}
 
public class BMW320 extends BMW {
	public BMW320() {
		System.out.println("制造-->BMW320");
	}
}
public class BMW523 extends BMW{
	public BMW523(){
		System.out.println("制造-->BMW523");
	}
}

工厂类

public class Factory {
	public BMW createBMW(int type) {
		switch (type) {
		
		case 320:
			return new BMW320();
 
		case 523:
			return new BMW523();
 
		default:
			break;
		}
		return null;
	}
}

用户类

public class Customer {
	public static void main(String[] args) {
		Factory factory = new Factory();
		BMW bmw320 = factory.createBMW(320);
		BMW bmw523 = factory.createBMW(523);
	}
}

3.优点

         简单工厂模式提供了专门的工厂类用于创建对象，实现类对象的创建和使用的职责分离，客户端不需要知道所创建的具体产品类的类名以及创建过程，只需要具体产品所对应的参数即可。通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

4.缺点

        在于不符合“开闭原则”，每次添加新产品就需要修改工厂类。在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展维护，并且工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。

为了解决简单工厂模式的问题，出现了工厂方法模式。

工厂模式

        工厂方法模式将工厂抽象化，并定义一个创建对象的接口。每增加新产品，只需增加该产品以及对应的具体实现工厂类，由具体工厂类决定要实例化的产品是哪个，将对象的创建与实例化延迟到子类，这样工厂的设计就符合“开闭原则”了，扩展时不必去修改原来的代码。在使用时，用于只需知道产品对应的具体工厂，不需要关注具体的创建过程，甚至不需要知道具体产品类的类名，当我们选择哪个具体工厂时，就已经决定了实际创建的产品是哪个了。

        但缺点在于，每增加一个产品都需要增加一个具体产品类和实现工厂类，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。

1.UML图

抽象工厂 AbstractFactory： 工厂方法模式的核心，是具体工厂角色必须实现的接口或者必须继承的父类，在 Java 中它由抽象类或者接口来实现。

具体工厂 Factory：被应用程序调用以创建具体产品的对象，含有和具体业务逻辑有关的代码

抽象产品 AbstractProduct：是具体产品继承的父类或实现的接口，在 Java 中一般有抽象类或者接口来实现。 

具体产品 Product：具体工厂角色所创建的对象就是此角色的实例。

代码实现

产品类

abstract class BMW {
	public BMW(){}
}
public class BMW320 extends BMW {
	public BMW320() {
		System.out.println("制造-->BMW320");
	}
}
public class BMW523 extends BMW{
	public BMW523(){
		System.out.println("制造-->BMW523");
	}
}

工厂类；

interface FactoryBMW {
	BMW createBMW();
}
 
public class FactoryBMW320 implements FactoryBMW{
 
	@Override
	public BMW320 createBMW() {
		return new BMW320();
	}
 
}
public class FactoryBMW523 implements FactoryBMW {
	@Override
	public BMW523 createBMW() {
		return new BMW523();
	}
}

用户类

public class Customer {
	public static void main(String[] args) {
		FactoryBMW320 factoryBMW320 = new FactoryBMW320();
		BMW320 bmw320 = factoryBMW320.createBMW();
 
		FactoryBMW523 factoryBMW523 = new FactoryBMW523();
		BMW523 bmw523 = factoryBMW523.createBMW();
	}
}