• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

设计模式 #2 (工厂模式)

开发技术 开发技术 1周前 (09-14) 19次浏览

设计模式 #2 (工厂模式)


文章中所有工程代码和UML建模文件都在我的这个GitHub的公开库—>DesignPattern。Star来一个好吗?秋梨膏!


简述 :提供一种创建对象的最佳方式。

在工厂模式中,我们在创建对象时不会对客户端暴露创建逻辑,并且是通过使用一个共同的接口来指向新创建的对象。

面向接口(抽象)编程?闻到内味了吗?7大设计原则中的依赖倒置原则迪米特法则接口隔离原则

当然不止用到了一个原则,一般设计模式都是多个设计原则的集合体。

简单工厂模式

简述:创建产品接口,需要产品时,利用工厂进行创建即可。

# 反例 :

public class negtive {
/*===============服务端======================*/
    interface Food{
        void eat();
    }

    static class Noodles implements Food{
        @Override
        public void eat() {
            System.out.println("吃面条。。。。。");
        }
    }

/*=================客户端===================*/
    public static void main(String[] args) {
        Food food01 = new Noodles();
        food01.eat();
    }
}

UML类图如下:

设计模式 #2 (工厂模式)

这时候,产品来改需求来了,“哥,你先把刀放下。咱们现在这 Noodles改名了,得改个特牛逼的名字Spaghetti,让用户记住咱们这是西餐意大利面。”

这时候,因为你原有设计是上面的反例,你得能从修改服务端的源代码开始,再修改客户端源代码。以后再有改名这类事,你还要把刀拿出来放桌上给产品看。

这种设计过于脆弱,因为这样服务端源代码和客户端源代码是耦合的,改变会牵一发而动全身。

# 正例:

public class postive {

    /*===============服务端======================*/
    interface Food{
        void eat();
    }

    static class Spaghetti implements Food {
        @Override
        public void eat() {
            System.out.println("吃西餐面条。。。。。");
        }
    }

    static class FoodFactory {
        public Food getFood(int num){
            Food food =null;
            switch (num){
                case 1 :
                    food = new Spaghetti();
            }
            return food;
        }
    }

    /*=================客户端===================*/
    public static void main(String[] args) {
        FoodFactory foodFactory = new FoodFactory();
        Food food01 = foodFactory.getFood(1);
        food01.eat();
    }
}

UML类图如下:

设计模式 #2 (工厂模式)

通过这样一个正例,把创建对象的代码全交给服务端处理,将服务端代码和客户端代码进行了解耦。以后产品再找你聊天是不是可以暂时把刀收起来了?

这样做的好处,不只是服务端开发人员受益,当服务端代码修改时,客户端也不知道,也不需要知道。

这样的设计模式并不是十全十美的,任何一种设计模式都不会是十全十美的。只是根据业务逻辑在各方面进行取舍。

简单工厂模式的缺点

  • 客户必须记住工厂中常量和具体产品的映射关系。
  • 一旦产品品种体量增大到一定程度,工厂类将变得非常臃肿。
  • 最致命的缺陷,增加产品时,就要修改工厂类。违反开闭原则

工厂方法模式

简述:为了进行扩展,不违反开闭原则。

这里是基于简单工厂模式进行改进。

# 正例:

public class postive {
    /*===============服务端======================*/
    //-----------------------产品--------------------
    interface Food{
        void eat();
    }

    static class Spaghetti implements Food {
        @Override
        public void eat() {
            System.out.println("吃西餐面条。。。。。");
        }
    }

    //新增产品
    static class Rice implements Food {
        @Override
        public void eat() {
            System.out.println("吃米饭。。。。。");
        }
    }

    //--------------------------工厂-----------------------
     interface FoodFactory {
         Food getFood();
    }

    static class SpaghettiFactory implements FoodFactory{

        @Override
        public Food getFood() {
            return new Spaghetti();
        }
    }

    //新增产品工厂
    static class RiceFactory implements FoodFactory{

        @Override
        public Food getFood() {
            return new Rice();
        }
    }

    /*=================客户端===================*/
    public static void main(String[] args) {
         FoodFactory foodFactory = new  SpaghettiFactory();
         Food food01 = foodFactory.getFood();
        food01.eat();
    }
}

UML类图如下:

设计模式 #2 (工厂模式)

针对简单工厂违反开闭原则的这一缺陷,工厂方法模式进行优化。可以看到此时再去增加产品,不再需要修改工厂类,而是增加相应的产品类和工厂类即可。这是符合开闭原则的。

这里就会有聪明的小问号有很多朋友了:

  1. 如果源代码作者修改相关工厂类的类名,那这时候调用工厂类的客户端代码就需要修改了,这不如简单工厂呢?

首先这里要明确一个概念,工厂类在实际使用中,是相当于接口类的,接口类一般不允许进行修改(非必须),工厂类作者有责任,有义务保证工厂类的类名是稳定的,也就是说,工厂类是比产品类更加稳定的。

  1. 既然使我们后面自己扩展的Rice类,为什么不直接实例化它,直接使用。我们就是作者,为什么不能直接使用?

这里需要扩展一下,有时候一个产品类并不是孤立的,它和其他类一起组成一个服务框架。

下面增加一些类:

	/*===============服务端======================*/	  
	//------------------------产品质检流程-----------------------、

    static class QualityInspection {

        public void checking(FoodFactory foodFactory){
            System.out.println("我是人肉质检员。。。。。准备开吃 -_- ");
            Food food = foodFactory.getFood();
            food.eat();
        }
    }
    /*=================客户端===================*/
    public static void main(String[] args) {
        FoodFactory foodFactory01 = new  SpaghettiFactory();
        FoodFactory foodFactory02 = new  RiceFactory();

        QualityInspection inspection = new QualityInspection();
        inspection.checking(foodFactory02);
        inspection.checking(foodFactory01);

设计模式 #2 (工厂模式)

UML类图如下:

设计模式 #2 (工厂模式)

这时候,如果Rice没有他的工厂类,甚至都没办法参加质检,那还怎么卖?

所以编写工厂类并不只是单纯为了实例化某些产品类,而是能让配套服务通过工厂接口,得以调用工厂创建产品实例。

有的小朋友大大的眼睛里还有疑惑:那为什么QualityInspectionchecking方法不直接调用Food接口再进行产品的实例化呢?

这时候回到简单工厂模式,产品类不同于工厂类,它是善变的,它会随着需求的变化而变化,这时候,直接依赖产品类的各种方法,将需要被修改,违反开闭原则。这是死路,小朋友别杠了。哈哈哈。

当然,工厂方法模式也是有缺陷的:

  • 当业务需要的类型变多,目前只有食物,当产生饮料,日用品等类别时,我们又要创建新的工厂来实现,造成代码重复臃肿。

抽象工厂模式

针对工厂方法模式的缺陷,抽象工厂模式将进行改进,一个工厂负责创建一个产品簇的对象。

关于产品簇:是指多个存在内在联系的或者存在逻辑关系的产品。

设计模式 #2 (工厂模式)

简述:在抽象工厂模式中,接口是负责创建一个相关对象的工厂,不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。

抽象工厂模式(Abstract Factory Pattern)是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。

# 正例:

public class postive {
    /*===============服务端======================*/
    
    //-----------------------产品--------------------
    /*----------------螺丝---------------------*/
    interface Screw{
        void createScrew();
    }

    static class Screw_06 implements Screw {
        @Override
        public void createScrew() {
            System.out.println("create Screw_06 666666。。。。。");
        }
    }

    static class Screw_08 implements Screw {
        @Override
        public void createScrew() {
            System.out.println("create Screw_08 8888888。。。。。");
        }
    }
    /*----------------螺母---------------------*/
    interface Nut{
        void createNut();
    }

    static class Nut_06 implements Nut {
        @Override
        public void createNut() {
            System.out.println("create Nut_06 666666。。。。。");
        }
    }

    static class Nut_08 implements Nut {
        @Override
        public void createNut() {
            System.out.println("create Nut_08 8888888。。。。。");
        }
    }
    
    
    //--------------------------工厂-----------------------
    interface ComponentsFactory {
        Screw getScrew();
        Nut getNut();
    }
    /*----------------6号工厂---------------------*/
    static class Factory_666 implements ComponentsFactory {

        @Override
        public Screw getScrew() {
            return new Screw_06();
        }

        @Override
        public Nut getNut() {
            return new Nut_06();
        }
    }

    /*----------------8号工厂---------------------*/
    static class Factory_888 implements ComponentsFactory {

        @Override
        public Screw getScrew() {
            return new Screw_08();
        }

        @Override
        public Nut getNut() {
            return new Nut_08();
        }
    }

    //------------------------产品质检流程-----------------------、
    static class QualityInspection {

        public void checking(ComponentsFactory Factory){
            System.out.println("我是人肉质检员。。。。。等待产出零件 -_- ");
            Screw screw = Factory.getScrew();
            Nut nut = Factory.getNut();
            screw.createScrew();
            nut.createNut();
            System.out.println("开始质检.......");
            System.out.println("      ");
        }
    }
    
    /*=================客户端===================*/
    public static void main(String[] args) {
        ComponentsFactory Factory01 = new   Factory_666();
        ComponentsFactory Factory02 = new   Factory_888();

        QualityInspection inspection = new QualityInspection();
        inspection.checking(Factory01);
        inspection.checking(Factory02);
    }
}

UML类图如下:

设计模式 #2 (工厂模式)

可以看到,如果在需要进行一种N号螺丝或者螺母的扩展,只需要增加一个实现N号螺丝或者螺母接口的产品类,利用一个新增N号工厂进行创建即可。

可以看到,抽象工厂仍然保持着简单工厂模式和工厂方法模式的优点:

  • 服务端代码和客户端代码是低耦合的。(简单工厂模式)
  • 所有这一切动作都是新增,不是修改,符合开闭原则。

还新增了一个特有的优点

  • 抽象工厂有效减少了工厂的数量,一个工厂就生产同一个产品簇的产品。

这下产品来改需求,是不是还可以笑嘻嘻跟他聊会天了?

再次强调,一个抽象工厂负责创建同一个产品簇的对象。而产品簇是指多个存在内在联系的或者存在逻辑关系的产品。也就是6号工厂只生产6号的零部件,不负责生产8号零部件。不能不同产品簇的产品混合到一个工厂中进行生产。

缺陷:当增加产品簇时(增加68号螺帽的生产),这时候就要修改以前工厂(68号工厂)的源代码了。


总结就是:

  • 当产品簇比较固定时,考虑使用抽象工厂。
  • 当产品簇经常变动时,不建议使用抽象工厂。

喜欢 (0)