设计模式--------工厂模式

工厂模式

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

分类：

• 简单工厂模式

• 工厂方法模式

• 抽象工厂模式

 

这里准备了一个小例子，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,简单的说就是，用户不用找第三方汽车工厂，直接找生产厂就行，这样就完成了进一步解耦

 

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

 

抽象工厂模式

关键字：

1. 产品族

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

 

我对抽象工厂的理解，就是把对象更细的拆分，比如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不过是他的细节，并不能算是对象，这种模式经常在开源框架中出现。