工厂模式

模式核心：创建者和调用者的分离

分类：

简单工厂模式

工厂方法模式

抽象工厂模式

 

这里准备了一个小例子，BaoMa和QQ都是实现了Car这个接口

当我们想要生成对象的时候，相信大多数人就是这样

public class User { Car car = new BaoMa(); Car car1 = new QQ(); }

这样做没有什么不对，只是类中不仅出现了Car，还出现了BaoMa和QQ类，有什么不妥呢，从调用者角度来讲，他就知道了许多不用知道的东西，最好的比方就是司机知道了怎么造汽车；

UML视图就如上所示（画的有点糙。。。）

可以看到User对所有类都有关系，这不是我们希望的，所以要引入工厂模式

 

 

简单工厂模式

在项目中多加入一个CarFactory，

public class CarFactory { public static Car createBaoMa() { return new BaoMa(); } public static Car createQQ() { return new QQ(); } }

然后对应user类变成了

public class User { Car BaoMa = CarFactory.createBaoMa(); Car QQ = CarFactory.createQQ(); }

UML图示

新的结构变成了这样，也许有人会说不对啊，只有变复杂了，其实你想现在只有QQ和BaoMa，要是以后多个别的类别呢，按照以前User是不是又要多关联一次对象，现在User只需要控制Car和CarFactory，就能控制整个结构，这就是调用者与创建者的分离（解耦）；

 

缺点：违反开闭原则，即每一次扩展都需要修改

 

工厂方法模式

为了符合开闭原则，简单工厂进化，可以很清楚的看到CarFactory变成了接口，多了QQFactory和BaoMaFactory

public interface CarFactory { Car createCar(); } public class BaoMaFactory implements CarFactory { @Override public Car createCar() { return new BaoMa(); } } public class User { Car BaoMa = new BaoMaFactory().createCar(); Car QQ = new QQFactory().createCar(); }

QQFactory的内容就不贴出来了，可以看到User类中直接new对应工厂的对象就行了，画一下UML图

可以看到User直接负责对应的Factory,简单的说就是，用户不用找第三方汽车工厂，直接找生产厂就行，这样就完成了进一步解耦

 

缺点：解耦带来的问题就是项目复杂度变高，一下子多出来好几个类，随着工厂的增多，调用者需要知道的工厂也越来越多。

 

抽象工厂模式

关键字：

产品族

对单个产品的新增无能为力

 

我对抽象工厂的理解，就是把对象更细的拆分，比如BaoMA，车就有高端（heigh）和低端（low），里面的零件就会有所区别，我们假设一辆车就是由引擎（engine），座椅（seat），和外壳（shell）组成，缺一不可，这三类就能成为产品族；

 

public interface Engine { void quality(); } class HeightEngine implements Engine { @Override public void quality() { System.out.print("高端"); } } class LowEngine implements Engine { @Override public void quality() { System.out.print("低端"); } }

这个接口加两个内部类相信是很简单了，产品族剩下的两个也是这样

public interface CarFactory { Engine createEngine(); Seat createSeat(); Shell creatShell(); } class HeightCarFactory implements CarFactory { @Override public Engine createEngine() { return new HeightEngine(); } @Override public Seat createSeat() { return new HeightSeat(); } @Override public Shell creatShell() { return new HeightShell(); } } class LowCarFactory implements CarFactory { @Override public Engine createEngine() { return new LowEngine(); } @Override public Seat createSeat() { return new LowSeat(); } @Override public Shell creatShell() { return new LowShell(); } } public class User { CarFactory heightCarFactory = new HeightCarFactory(); Engine heightEngine = heightCarFactory.createEngine(); Seat heightSeat = heightCarFactory.createSeat(); Shell heightShell = heightCarFactory.creatShell(); CarFactory lowCarFactory = new LowCarFactory(); }

UMl视图就不画了，可以看到就是通过对象细节的继续拆分，然后将类继续拆分成接口。为什么不能新建一个引擎呢，因为在这个实例中Car已经是最小对象，engine不过是他的细节，并不能算是对象，这种模式经常在开源框架中出现。