【23种设计模式专题】二 工厂模式

程序猿学社的GitHub,欢迎Star
github技术专题
本文已记录到github

前言

通过上一篇文章,我们已经知道程序猿是有女(男)朋友,也知道如何保证只会有一个对象(男女朋友),本文我们来看一看工厂模式。

社长:“老王,我们开始继续23中设计模式之工厂模式”
隔壁老王: “社长,工厂模式有什么用,为什么要用工厂模式?”
社长: “我先买一个小关子,先来看一看传统的写法”

小故事

周末一大早,6点钟左右,我就被吵醒,然后一脸呆萌呆萌的看着我,原来是忘记给我家乖乖喂食物咯,看了一下存放猫粮的袋子,也弹尽粮绝咯,只能上宠物店去购买猫粮。他的名字叫汤圆

传统方式

通过代码,我们实现去宠物店购买猫粮的这样一个需求。

package com.cxyxs.designmode.factory;
/**
 * Description:
 * Author: 程序猿学社
 * Date:  2020/4/3 23:16
 * Modified By:
 */
public interface PetShop {
    void buy();
}

class  Meat implements  PetShop{

    @Override
    public void buy() {
        System.out.println("社长给汤圆购买肉干");
    }
}

/**
 * 提供者
 * =======================
 * 调用者
 */
class  Test{
    public static void main(String[] args) {
        PetShop ps = new Meat();
        ps.buy();
    }
}


  • 这种写法违反了迪米特法则也就是最少知道原则,通俗的来讲,就是一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类来说,无论逻辑多么复杂,都尽量地的将逻辑封装在类的内部,对外除了提供的public方法,不对外泄漏任何信息。
  • 结合生活实际理解,例如我这里是去购买肉干,我有必要知道这个肉是如何生产出来的吗
  • 实际上也违反勒开闭原则,对扩展开放(提供者),对修改关闭(调用者)
    例如我们把类Meat改为Meat1,我们可以发现,我们需要修改两个地方,一个是提供者,还有一个是调用者,两边都要改动,这就违反了对修改关闭这一条,也没有实现程序的一个解耦。

隔壁老王: “社长,你也说了,上面这种方式,提供者一变,调用者就得跟着变,在项目开发过程中,如何也出现这样的问题,那大家还能不能愉快的玩耍咯”
社长:“别急,我们可以通过简单工厂来实现”

简单工厂(第一种)

从设计模式的类型上来说,简单工厂模式是属于创建型模式,又叫做静态工厂方法(Static Factory Method)模式,但不属于23种GOF设计模式之一。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例

肉干毕竟不能当饭吃,所以,还得买猫粮,肉干只能当零食吃。所以这时候我们的需求又发生了改变。

  • 不清楚这个图如何画的,可以百度查一下UML类图
package com.cxyxs.designmode.factory.simple;

/**
 * Description:宠物店
 * Author: 程序猿学社
 * Date:  2020/4/3 23:16
 * Modified By:
 */
public interface PetShop {
    void buy();
}

class  Meat implements  PetShop{

    @Override
    public void buy() {
        System.out.println("社长给汤圆购买肉干");
    }
}

class  Foot implements  PetShop{

    @Override
    public void buy() {
        System.out.println("社长给汤圆购买猫粮");
    }
}


class  CatFootFacoty{
    public  static  PetShop buy(String name){
        switch (name){
            case "猫粮":
                return  new Foot();
            case "肉干":
                return  new Meat();
        }
        return  null;
    }
}

/**
 * 提供者代码
 * =======================
 * 调用端代码
 */
class  Test{
    public static void main(String[] args) {
        PetShop ps = CatFootFacoty.buy("肉干");
        PetShop ps1 = CatFootFacoty.buy("猫粮");
        ps.buy();
        ps1.buy();
    }
}


好处:

  • 在这里借助了一个工厂类CatFootFacoty,实现解耦,我们不用关心肉干和猫粮是生产生产的,只需要告诉工厂,我需要这两样东西。由工厂统一管理。
  • 产品很少的情况下,可以实现简单工厂模式

缺点:

  • 如果产品一多,工厂类就会变得很臃肿,不利于维护,同时他违反咯开闭原则,开闭原则很重要的一点,当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有代码来实现变化。
  • 例如我现在需要新增一个购买鱼的产品需求,需要新增一个鱼类,再修改工厂类,类会变得越来越多,如果上百个产品,这就意味着上百个类,增加了程序的复杂度。

工厂方法模式(第二种)

跟简单工厂相比,工厂方法模式是简单工厂的plus版本,越来越流程化。不像简单工厂一个工厂,既生产肉干,又生产猫粮等等,工厂方法模式,就是把具体生产的工作,交给具体的工厂来负责,例如,生产肉干的是一个工厂,生产猫粮的又是一个工厂。

  • 所以工厂方法模式符合开闭原则

社长: “我们刚刚已经了解到简单工厂一些优缺点,其中很重要的一点就是不符合开闭原则,我们来看一看工厂方法模式”
社长: “既然工厂方法模式是简单工厂的plus版本,我们直接把简单工厂的代码拿过来,新创建一个包methodmodel,老王,有没有跟上我的节奏”
隔壁老王: “欧了,已经搞定咯,如何改造成工厂方法模式*
社长: "话不多说,先看看类图,再看代码 "

  • 这个类图代码写完后,可以自动生成,在idea中,右击

    再把对应的类拖进来就可以自动生成,
package com.cxyxs.designmode.factory.methodmodel;


/**
 * Description:宠物店
 * Author:程序猿学社
 * Date:  2020/4/3 23:16
 * Modified By:
 */
public interface PetShop {
    void buy();
}

class  Meat implements PetShop {

    @Override
    public void buy() {
        System.out.println("社长给汤圆购买肉干");
    }
}

class  Foot implements PetShop {

    @Override
    public void buy() {
        System.out.println("社长给汤圆购买猫粮");
    }
}


interface  Factory{
    PetShop food();
}

class   MeatFactory implements  Factory{

    @Override
    public PetShop food() {
        return new Meat();
    }
}

class  FootFactory implements  Factory{

    @Override
    public PetShop food() {
        return new Foot();
    }
}



/**
 * 提供者代码
 * =======================
 * 调用端代码
 */
class  Test{
    public static void main(String[] args) {
        Factory factory = new MeatFactory();
        FootFactory footFactory = new FootFactory();

        PetShop food = factory.food();
        PetShop food1 = footFactory.food();

        food.buy();
        food1.buy();
    }
}


隔壁老王: “社长,你这代码,我没有看出什么好处来,只知道你这代码越来越复杂,绕的头都晕咯。”
社长: “老王,别急呀,我们之前已经知道简单工厂是不符合开闭原则的,也就是说,尽量不要在已经的代码上进行修改,应该进行扩展”
社长: “我家的汤圆现在已经不满足于肉干和猫粮咯,需要吃鱼,我们看看,我们如何在现有的代码上进行改动”

/**
 * 扩展吃鱼的部分开头
 */
class  Fish implements PetShop {

    @Override
    public void buy() {
        System.out.println("社长给汤圆购买小鱼鱼");
    }
}
class FishFactory implements  Factory{

    @Override
    public PetShop food() {
        return new Fish() ;
    }
}

/**
 * 提供者代码
 * =======================
 * 调用端代码
 */
class  Test{
    public static void main(String[] args) {
        Factory factory = new MeatFactory();
        FootFactory footFactory = new FootFactory();

        Factory fishFactory = new FishFactory();

        PetShop food = factory.food();
        PetShop food1 = footFactory.food();
        PetShop food2 = fishFactory.food();

        food.buy();
        food1.buy();
        food2.buy();
    }
}
  • 扩展产品,具体工厂也跟着扩展,不需要修改以前的代码,遵守了开闭原则。

好处:

  • 提供者修改代码后,调用者是不知道的,迪米特法则,也就是最少知道原则。
  • 在简单工厂上做咯优化,扩展产品,不需要修改以前的代码,只需要扩展一个产品和一个具体工厂即可

隔壁老王: “就拿你上面main方法里面的MeatFactory举例,假设MeatFactory类变为MeatFactory123,还是需要修改提供者和调用者两边的代码”
社长 “工厂名称有一套规范,只需要提供者保证尽量不改动类名就行,不然就是一个死循环,看看mybatis工厂类,版本变动,工厂名也不会变动。mybatis开发就相当于提供者,我们使用人员,就相当于调用者,如果mybatis工厂名变动,我们开发也不知道,这体验是不是很不好。所以,这个问题,不用担心,都有规范的”

抽象工厂模式(第三种)

社长: “我们之前只是很简单的实现吃,猫还会吃、睡等行为(多个产品等级)。产品等级一多,工厂类就会变得越来越臃肿”

使用工厂方法模式

  • 需要使用到12个类,工厂的涉及类就有6个
package com.cxyxs.designmode.factory.abstrastinterface;

/**
 * Description:
 * Author: 程序猿学社
 * Date:  2020/4/4 18:20
 * Modified By:
 */
public interface Foot {
    void eat();
}

class  Meat implements  Foot{

    @Override
    public void eat() {
        System.out.println("给汤圆吃肉干");
    }
}

class  Fish  implements  Foot{

    @Override
    public void eat() {
        System.out.println("给汤圆吃小鱼仔");
    }
}

interface Toy{
    void play();
}

class  CatTeaser implements Toy{

    @Override
    public void play() {
        System.out.println("社长利用逗猫棒跟汤圆玩耍");
    }
}

class Ball implements  Toy{

    @Override
    public void play() {
        System.out.println("汤圆一个人跟小球进行玩耍");
    }
}

/**
 * 食物工厂代码
 */
interface FootFactory{
    public Foot proFoot();
}
class MeatFactory implements  FootFactory{

    @Override
    public Foot proFoot() {
        return new Meat();
    }
}

class FishFactory implements  FootFactory{

    @Override
    public Foot proFoot() {
        return new Fish();
    }
}

/**
 * 玩具工厂
 */
interface ToyFactory{
    public Toy proToy();
}
class  CatTeaserFactory implements  ToyFactory{

    @Override
    public Toy proToy() {
        return new CatTeaser();
    }
}

class  BallFactory implements  ToyFactory{

    @Override
    public Toy proToy() {
        return new Ball();
    }
}

使用抽象工厂实现

社长: “先看看类图,再根据类图实现对应的代码”

package com.cxyxs.designmode.factory.abstrastinterface.plus;

/**
 * Description:
 * Author: 程序猿学社
 * Date:  2020/4/4 18:20
 * Modified By:
 */
public interface Foot {
    void eat();
}

class  Meat implements Foot {

    @Override
    public void eat() {
        System.out.println("给汤圆吃肉干");
    }
}

class  Fish  implements Foot {

    @Override
    public void eat() {
        System.out.println("给汤圆吃小鱼仔");
    }
}

interface Toy{
    void play();
}

class  CatTeaser implements Toy {

    @Override
    public void play() {
        System.out.println("社长利用逗猫棒跟汤圆玩耍");
    }
}

class Ball implements Toy {

    @Override
    public void play() {
        System.out.println("汤圆一个人跟小球进行玩耍");
    }
}

/**
 * 食物工厂代码
 */
interface Factory{
    public Foot proFoot();
    public Toy proToy();
}

class MeatAndCatTeaserFactory implements Factory {

    @Override
    public Foot proFoot() {
        return new Meat();
    }

    @Override
    public Toy proToy() {
        return new CatTeaser();
    }
}

class FishAndBallFactory implements  Factory{

    @Override
    public Foot proFoot() {
        return new Fish();
    }

    @Override
    public Toy proToy() {
        return new Ball();
    }
}
  • 工厂类由之前的6个,变为3个。减少了工厂类的臃肿

优点:

  • 抽象工厂可以理解为简单工厂和工厂方法模式的一个汇总
  • 对产品进行了抽象,适合一些维度有关联的(也就是说,有逻辑关系),例如,我举的这个例子,在工厂方法中,会有吃的工厂和玩的工厂,而在抽象工厂中,直接把这两个具体工厂直接抽象出来,合二为一。

缺点:

  • 要求抽象的多个产品,之前有逻辑关系
  • 后续需要生产喝的东西,需要修改抽象工厂,同时各个具体工厂也需要修改

隔壁老王: “社长,在抽象工厂模式中,吃和玩都是捆绑的关系,你这是捆绑销售,如果,我只想要实现吃,应该怎么办?”
社长: “如果只想实现吃,就可以使用工厂方法模式,应该根据具体问题,具体选择,使用那个模式。”

总结:

  • 不管是简单工厂、工厂方法模式、抽象工厂模式,我们应该灵活运用,主要的目的,还是为了解耦,写出可扩展性、可读的代码。

原创不易,不要白嫖,觉得有用的社友,给我点赞,让更多的老铁看到这篇文章。
因技术能力有限,如文中有不合理的地方,希望各位大佬指出,在下方评论留言,谢谢,希望大家一起进步,一起成长。

作者:程序猿学社
原创公众号:『程序猿学社』,专注于java技术栈,分享java各个技术系列专题,以及各个技术点的面试题。
原创不易,转载请注明来源(注明:来源于公众号:程序猿学社, 作者:程序猿学社)。

程序猿学社 CSDN认证博客专家 Java Spring Boot
公众号程序猿学社,关注社长,跟着社长一起学习github文章系统整理https://github.com/ITfqyd/cxyxs
©️2020 CSDN 皮肤主题: 程序猿惹谁了 设计师: 上身试试 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值