java设计模式(二)工厂模式

2017-12-15  本文已影响0人  IT废柴

什么是工厂模式

工厂模式就是将一个个类实例化的时候,通过一个工厂(管理类)来统一实例化。


比如:我现在是雪糕厂长,我们厂子生产各式雪糕(各种类)
1、现在你递张小纸条,上面写着“甜筒”(传入相关参数),
2、我这边收到之后,就做个甜筒给你(返回一个甜筒类的实例)。
3、然后另外一个人递了张写着“老冰棍”的小纸条,
4、我收到后,就做了个老冰棍给他。


说白了就是,不直接从目的类获取实例,而是通过一个统一的窗口来获取。这时,应该就有人说,MDZZ,这不是闲的蛋疼吗。兄弟,我给你讲,我TM也是这样想的。但是,在获取简单实例对象时候,确实闲的很鸡肋。但是如果,在获取实例对象的时候,需要一系列预操作的时候,工厂模式就闲的给力多了。
就好比,语句和方法的关系,我们需要的功能需要一堆语句才能实现的时候,我们不会在每次使用这个功能的时候都写一大堆语句,而是封装成方法,在使用的时候去调用。工厂模式大概就这个意思了。

常用工厂模式分类

根据目前各大博客网站搜索结果来看,工厂模式主要分为三种:

简单工厂模式

所谓简单工厂模式,就是最简单的实现方式。先上代码:

public class Car {
}

public class Audi extends Car {
}

public class AuTuo extends Car {
}

public class CarFactory {
    public Car getCar(String carName) {
        Car car = null;
        switch (carName) {
        case "Audi":
            car = new Audi();
            break;
        case "AuTuo":
            car = new AuTuo();
            break;
        }
        return car;
    }
}

public class Buyer {
    public void buy() {
        CarFactory factory = new CarFactory();
        Car carHadBought = factory.getCar("Audi");
    }
}

这就是简单工厂模式,说实话,并不简单啊,毕竟还是用到了继承,体现出了多态啊~
简单工厂模式就是简单的运用了继承的关系,父类引用子类对象。然后将获取实例全部整合到一个factory类中。这样在使用的时候,通过factory传参数获取就好了。但是 还记得我在《习惯性废话》中说的六大准则吗?我们从“开闭原则”的特性来分析一下简单工厂模式。
“开闭原则”主要是指:对扩展开放;对修改封闭。说白了就是说,我现在要改功能了,但是我不能对之前写的代码进行修改,但是我可以在之前代码的基础上进行拓展,继承也好,其他方式也好。
所以,我们来看简单工厂模式,现在我们工厂有奥迪和奥拓这两种车,老板又谈下一个大单子,工厂新增奔驰车。按照简单工厂模式的工厂类的实现来看,我们要新增一个车型,就得在原始类中新增一个case。这样明显违背了“开闭原则”,对程序员造成的伤害是不可估量的。
所以,需要对简单工厂模式进行进阶优化。


工厂方法模式

上文中说到,简单工厂模式的短板出现在工厂类不够灵活。那么我们就对工厂类进行优化。那么我们来分析一下,为什么要优化,然后再解决怎么优化。
使用简单工厂模式,当新增类时,需要去修改工厂类的方法,这样违背了开闭原则,容易伤亡程序员。分析一下,为什么新增时,需要改动工厂类。分析一下之后,得出原因:因为只有一个汽车工厂啊,这个工厂生产所有的汽车类。那么,我们多开几个厂不就好了吗?奥迪车就由奥迪厂生产,要拿奥迪就去奥迪厂拿就好了啊。是不是豁然开朗了?那这样分开后,岂不是失去了工厂模式的意义。实则不然,因为你想,奥迪厂肯定不止生产一种奥迪车,奥迪厂和所有车型的关系不就正是工厂模式所适用的场景吗!
问题找到了,那么怎么解决呢?
既然需要多个工厂,那么生成多个工厂不就行了,给定一个标准,每次新增品牌车的时候,我就新增一个工厂,新增的工厂按照给定的标准建造就好了。需要什么牌子的车我就从哪个牌子的厂拿就好了。指定标准,想到了什么?抽象类,接口啊!
看代码:

public class Car {
}

public class Audi extends Car {
}

public class AuTuo extends Car {
}
public abstract class AbstractCarFactory {
    public abstract Car getCar() ;
}

public class AudiFactory extends AbstractCarFactory{
    @Override
    public Car getCar() {
        return new Audi();
    }
}

public class AuTuoFactory extends AbstractCarFactory {
    @Override
    public Car getCar() {
        return new AuTuo();
    }
}
public class Buyer {
    public void buy() {
        AbstractCarFactory factory = new AudiFactory();
        Car carHadBought =factory.getCar();
    }
}

这就是典型的抽象类的运用,当然用接口也是ok的。完全看个人习惯了。
可以看到我们用了一个抽象类来约定了工厂标准,如果此时我们需要新增奔驰车,那么我们相应的新增一个奔驰厂,然后继承AbstractCarFactory类就好了。需要奔驰车的时候,用奔驰厂去获取实例就好了。

抽象工厂模式

抽象工厂模式参考http://blog.51cto.com/lavasoft/11674,写的很不错!
每个模式都是针对一定应用场景的解决方案。抽象工厂模式面对的问题是多产品等级结构的系统设计。这里涉及到两个概念:产品族和产品等级
产品族:是指位于不同产品等级结构中,功能相关联的产品组成的家族。比如,奥迪的高档车和低档车,这称为一个产品族。奥拓也有高档车和低档车,这也是一个产品族
产品等级:就是指高档和低档的等级区分。这里大多情况下是,每个产品族都遵循这个产品等级。


偷了张图, 从上图可以看出,抽象工厂模式的每个工厂创造出来的都是一族产品,而不是一个或者一组。组是可以随意组合的!抽象工厂模式其实是对工厂方法模式的复杂场景的应用。但是在一定程度上,并没有保障“开闭原则”,后面会讲到。
为此我总结了一个公式:
//抽象出所有奧迪车的共同点,这里假设所有的奥迪车都是黑色的
public abstract class Audi  {
    public  void black() {
        System.out.println(" Audi car is Black");
    }
}

//抽象出所有奥拓车的共同点,这里假设所有的奥拓车都是白色的
public abstract class AuTuo  {
    public  void white() {
        System.out.println("AoTuo car is white");
    }
}
public abstract class CarFactory{
    //生产奥迪车
    public abstract Audi productAodi();
    //生产奥迪车
    public abstract AuTuo productAoTuo();
}
第2、3步骤是定义抽象工厂和抽象产品。x轴是分别创建类,而y轴中的每个参数都以方法集合在一个类中。
public class GaodangAodi  extends Audi{
    public GaodangAodi() {
        System.out.println("This is Gaodang Aodi");
    }
}
public class GaodangAotuo  extends AuTuo{
    public GaodangAotuo() {
        System.out.println("This is Gaodang Aotuo");
    }
}
public class DidangAodi  extends Audi{
    public DidangAodi() {
        System.out.println("This is Didang Aodi");
    }
}
public class DidangAotuo  extends AuTuo{
    public DidangAotuo() {
        System.out.println("This is Didang aotuo");
    }
}
//高档工厂生产高档奥迪和高档奥拓
public class GaodangFactory  extends CarFactory{
    @Override
    public Audi productAodi() {
        return new GaodangAodi();
    }
    @Override
    public AuTuo productAoTuo() {
        return new GaodangAotuo();
    }
}

//低档工厂生产低档奥迪和低档奥拓
public class DidangFactory extends CarFactory {
    @Override
    public Audi productAodi() {
        return new DidangAodi();
    }
    @Override
    public AuTuo productAoTuo() {
        return new DidangAotuo();
    }
}


至此,我们的抽象工厂模式的设计就完成了,这里有两个等级工厂实体类,当我们新增等级的时候,比如我们要新增中档奥迪和中档奥拓的时候,新增中档奥迪实体类,中档奥拓实体类,和中档工厂就可以了。
但是如果我们要新增一个奔驰系列的产品族,那么就比较难受了,因为我们需要去再工厂抽象类CarFactory中去增加生产奔驰的方法,而我们的每个工厂实体类也需要相应的改动,所以说这里破坏了“开闭原则”!

总结

工厂模式有时候会显得很臃肿,是因为这些工作完全是可以单独存在的,但是说回工厂模式的应用场景:当我们创建实例十分麻烦的时候,在获取实例的时候,更希望的是我不去关心创建的关系和流程,我只得到我想要的实例就好了。可以翻上去看看什么是工厂模式。

工作之余写的,有些代码写的比较仓促,不是很规范,还请多多包涵,如果你非要说的话,那我也不改了!!!!
上一篇下一篇

猜你喜欢

热点阅读