一般提到工厂模式都指的是三种：简单工厂、工厂方法、抽象工厂。
这三种的抽象度是依次增加的，耦合度是依次减小的。
下面分别学习一下。
简单工厂
以制造汽车为例，我们现在有A、B两种类型的汽车，每次制造都需要在程序中（客户端）new一个具体的类型的汽车对象出来，那么能不能把这些new操作封装起来，我们只需要输入类型就给我返回指定的new好的对象呢，这样子就不用客户端自己去new（制造）了，这个封装起来的类就是汽车工厂了，把制造汽车（new）的操作来交给汽车厂进行，我们只需要告诉他我们需要什么类型的汽车就行了。
代码如下：
首先是汽车接口及其实现类
public interface Car {
}
public class CarA implements Car {
public CarA(){
System.out.println("create----->car a");
}
}
public class CarB implements Car {
public CarB(){
System.out.println("create----->car b");
}
}
然后是汽车工厂
public class CarFactory {
public static Car createCar(String type){
if(type.equals("carA")){
return new CarA();
} else if (type.equals("carB")){
return new CarB();
}
return null;
}
}
测试
public class Test {
public static void main(String[] args) {
Car cara = CarFactory.createCar("carA");
Car carb = CarFactory.createCar("carB");
}
}
这个实现很简单，就是根据类型做了判断而已，并new出了不同类型的对象返回。
其实严格意义来讲简单工厂并不能算是设计模式，只是提供了简单的封装而已。
工厂方法
上面的简单工厂问题就在于，当我们的汽车类型不断的增加的时候，我们是需要去不断的修改我们的工厂方法的代码的，这显然是不对的，我们需要的是即使业务在不断的扩展，系统的原始代码是不能轻易改变的，也就是说这样的设计的弹性是很差的，甚至说是没有弹性的，因为只要有新的类型出现，就需要修改代码。
如何在新的类型出现的时候不变动我们原始的代码呢？那就只能是创建新的类来实现新的类型。也就是说，对于每一种类型，我们都为其提供一个工厂，我们还需要为这些工厂都需要有一些共同的约束，即创建一个接口。
也就是说，我们为每种类型的汽车都创建一个汽车厂，这个汽车厂就专门生产这种类型的汽车，我们需要什么汽车，就创建什么类型的汽车工厂，然后由其生产，并定义一个接口来约束汽车厂必须要进行的一些操作。在我们有新的业务来时，只需要创建该类型的汽车厂，实现需要的接口并提供其生产方式即可。这样子系统的弹性就大大增加了，也就是说很容易扩展。
代码：
首先是汽车接口以及实现类
public interface Car {
}
public class CarA implements Car {
public CarA(){
System.out.println("create----->car a");
}
}
public class CarB implements Car {
public CarB(){
System.out.println("create----->car b");
}
}
然后是汽车工厂接口以及实现类
public interface CarFactory {
Car createCar();
}
public class CarAFactory implements CarFactory {
@Override
public CarA createCar() {
return new CarA();
}
}
测试
public class CarBFactory implements CarFactory {
@Override
public CarB createCar() {
return new CarB();
}
}
public class Test {
public static void main(String[] args) {
CarAFactory carAFactory = new CarAFactory();
CarA cara = carAFactory.createCar();
CarBFactory carBFactory = new CarBFactory();
CarB carb = carBFactory.createCar();
}
}
抽象工厂
上面的工厂方法的实现确实在可扩展性方面有了很大的改进，但是，问题在于汽车是由很多部件组成的，同一款车CarA，其发动机和轮胎等部件有多种选择来组成，按照工厂方法的做法，将所有的组件的建造都放在汽车的建造中，最终组合成一辆车，那么如果客户需要指定某种型号的发动机的CarA该怎么办呢？没办法只能修改代码，将其中生产发动机的部分指定为指定型号的发动机。
那么我们不禁要想了，按照解耦的思想，可以把生产汽车这个动作拆分成先生产不同的组件，然后组装成汽车，每种组件都有其实现，如果需要更换组件或者有了新的组件，只需要创建一个新的该组件的类，然后在汽车组装的时候替换掉即可。
也就是在抽象方法工厂的基础上，进一步解耦，将汽车的组件变为工厂，组件的生产交给组件工厂，汽车工厂只负责组装就好了，按照不同的需求，我就组装不同的型号的组件来生成汽车就好了。
代码：
首先是发动机工厂接口及其实现类
public interface EngineFactory {
}
public class EngineAFactory implements EngineFactory {
public EngineAFactory(){
System.out.println("create----->engine a");
}
}
public class EngineBFactory implements EngineFactory {
public EngineBFactory(){
System.out.println("create----->engine b");
}
}
然后是轮子接口及其实现类
public interface WheelFactory {
}
public class WheelAFactory implements WheelFactory {
public WheelAFactory(){
System.out.println("create----->wheel a");
}
}
public class WheelBFactory implements WheelFactory {
public WheelBFactory(){
System.out.println("create----->wheel b");
}
}
然后是汽车接口及其实现类
public interface Car {
}
public class CarA implements Car {
public CarA(){
System.out.println("create----->car a");
}
}
public class CarB implements Car {
public CarB(){
System.out.println("create----->car b");
}
}
然后是汽车工厂接口及其实现类
public interface CarFactory {
Car createCar(EngineFactory engineFactory, WheelFactory wheelFactory);
}
public class CarAFactory implements CarFactory {
@Override
public CarA createCar(EngineFactory engineFactory, WheelFactory wheelFactory) {
return new CarA();
}
}
public class CarBFactory implements CarFactory {
@Override
public CarB createCar(EngineFactory engineFactory, WheelFactory wheelFactory) {
return new CarB();
}
}
测试
public class Test {
public static void main(String[] args) {
CarAFactory carAFactory = new CarAFactory();
CarA cara = carAFactory.createCar(new EngineAFactory(), new WheelAFactory());
CarBFactory carBFactory = new CarBFactory();
CarB carb = carBFactory.createCar(new EngineBFactory(), new WheelBFactory());
}
}
比较懒省事的都放在构造方法里简单打印了一下。
总之，抽象工厂就是在具体的工厂的实现的基础上，考虑其内部组件的组成，进一步解耦，将组件的生产也独立出来，这样系统的灵活性会更好。
以上就是个人学习中的见解。
