设计模式——1_4 外观(Facade)

这篇具有很好参考价值的文章主要介绍了设计模式——1_4 外观(Facade)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

定义

为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用

你可以把 外观模式 理解成控制面板,你可能拥有一部庞大的机器,但是为了使用他,你并不需要理解里面每一个螺丝的作用,只需要按照说明书去控制操作面板就可以调度他


图纸

设计模式——1_4 外观(Facade),设计模式,设计模式,外观模式,java


一个例子:自动生成一杯茶

很多人喜欢喝茶,但是又嫌沏茶太麻烦了。如果我们现在有一种机器,支持按一个按钮,就生成一杯茶到你手里。那他应该是啥样的呢?这次的例子因为要涉及到多个模块之间的协同,可能会显得比较复杂,我会尽我所能的简化他

准备好了吗?这次的例子开始了:


沏茶的流程

在没有任何自动化的情况下,我们沏茶是这样的:

设计模式——1_4 外观(Facade),设计模式,设计模式,外观模式,java

如果把他们转换成系统里的一部分的话,他们并不属于相同的模块,比如说:

煮水,肯定是属于 热水壶 的方法。可是一个 热水壶 ,怎么可能会有 冲出茶水 这样的方法定义呢?


所以很显然,上面这个流程里的步骤,需要多个模块的配合,就像这样:
设计模式——1_4 外观(Facade),设计模式,设计模式,外观模式,java

beans

//水
public class Water implements Comparable<Water> {

    /**
     * 数量
     */
    private float quantity;

    /**
     * 温度
     */
    private float temperature;

    public Water(float quantity, float temperature) {
        this.quantity = quantity;
        this.temperature = temperature;
    }

    public Water(float quantity) {
        this(quantity, 24);//默认水温24度
    }

    //创建一个空的Water对象
    public static Water createEmptyWater() {
        return new Water(0, 0);
    }

    /**
     * 加水
     */
    public void add(Water water) {
        quantity += water.quantity;
        if (temperature == 0) {
            this.temperature = water.temperature;
        }
        water.clear();
    }

    /**
     * 切割一些热水出去
     */
    public Water cut(float quantity) {
        //检查是否足够,如果足够则返还quantity为参数的冷水给client,如果不足则全部返还
        Water result;

        if (quantity < this.quantity) {
            //足够
            result = new Water(quantity, temperature);
            this.quantity -= quantity;
        } else {
            //不够或者刚好
            result = new Water(this.quantity, temperature);
            clear();
        }

        return result;
    }

    //清空当前水对象的信息
    private void clear() {
        this.quantity = 0;
        this.temperature = 0;
    }

    public float getQuantity() {
        return quantity;
    }

    public float getTemperature() {
        return temperature;
    }

    public void setTemperature(float temperature) {
        this.temperature = temperature;
    }

    /**
     * 是热水吗
     * 超过75度视为热水
     */
    public boolean isHot() {
        return temperature >= 75;
    }

    @Override
    public int compareTo(Water o) {
        return Float.compare(this.quantity, o.quantity);
    }
}

//茶叶
public class TeaLeaf {

    /**
     * 茶叶类型
     */
    private final String type;

    public TeaLeaf(String type) {
        this.type = type;
    }

    public String getType() {
        return type;
    }
}

//茶
public class Tea {

    private float quantity;//数量
    private final String describe;

    public Tea(String describe,float quantity) {
        this.describe = describe;
        this.quantity = quantity;
    }

    public String getDescribe() {
        return describe;
    }
}

水桶、热水壶和盖碗

//水桶
public class Bucket {

    //容量
    private final float capacity;
    //水桶里的水
    private final Water quantity;

    //生成一个空桶
    public Bucket(float capacity) {
        this.capacity = capacity;
        quantity = Water.createEmptyWater();
    }

    public Bucket(float capacity, float water) {
        this(capacity);

        addWater(new Water(water));
    }

    //往水桶里加水
    public boolean addWater(Water water) {
        //检查是否可以容纳,如果足够容纳,则把水全部加入,如果无法容纳则操作失败
        if (capacity - quantity.getQuantity() >= water.getQuantity()) {
            //可以容纳
            quantity.add(water);
            return true;
        }

        return false;//无法容纳
    }

    //给予别人水
    public Water getWater(float quantity) {
        return this.quantity.cut(quantity);
    }
}

//热水壶
public class Kettle {

    //容量
    private final float capacity;
    //当前水量
    private final Water quantity;

    public Kettle(float capacity) {
        this.capacity = capacity;
        this.quantity = Water.createEmptyWater();
    }

    //往热水壶里加水
    public boolean addWater(Water water) {
        //检查是否可以容纳,如果足够容纳,则把水全部加入,如果无法容纳则操作失败
        if (capacity - quantity.getQuantity() >= water.getQuantity()) {
            //可以容纳
            quantity.add(water);
            return true;
        }

        return false;//无法容纳
    }

    //加热水
    public void heatUpWater() {
        quantity.setTemperature(100);//加热到100度
    }

    //倒出水
    public Water getWater(float quantity) {
        return this.quantity.cut(quantity);
    }
}

//盖碗
public class Tureen {

    //容量
    private final float capacity;
    //当前水量
    private final Water quantity;
    //茶叶
    private TeaLeaf teaLeaf;

    public Tureen(float capacity) {
        this.capacity = capacity;
        this.quantity = Water.createEmptyWater();
    }

    //往盖碗里加水
    public boolean addWater(Water water) {
        //检查是否可以容纳,如果足够容纳,则把水全部加入,如果无法容纳则操作失败
        if (capacity - quantity.getQuantity() >= water.getQuantity()) {
            //可以容纳
            quantity.add(water);
            return true;
        }

        return false;//无法容纳
    }

    //生成茶
    public Tea generateTea(float teaQuantity) {
        if (!quantity.isHot()) {
            throw new RuntimeException("必须用热水煮茶");
        } else if (quantity.getQuantity() < teaQuantity) {
            throw new RuntimeException("盖碗里的水数量不足");
        } else {
            return new Tea("这是一份 " + teaLeaf.getType() + " 茶", teaQuantity);
        }
    }

    public TeaLeaf getTeaLeaf() {
        return teaLeaf;
    }

    public void setTeaLeaf(TeaLeaf teaLeaf) {
        this.teaLeaf = teaLeaf;
    }
}

现在我们把所需要的类都创建出来了, client(调用上下文) 可以 创建一个水桶对象A->从A对象里拿到水对象B->把B对象注入热水壶对象C…… ,就像上文说的那种没有任何自动化的方式去生成一杯茶

这对我们的程序来说肯定是不合理的,什么都交给 client 去做,那没有人知道到底会做出什么样的一杯茶,也许编写 client 的人突发奇想,跳过热水壶直接把冷水加入盖碗;又或者把做好的茶倒回水桶……这种情况下,你失去了对整个流程的控制,程序会因为千奇百怪的 client 出现各种各样的异常,除非所有人都遵守规则

理想状态下,我们希望代码可以跟全自动煮茶器一样,我只需要点击一个按钮(调用一个方法),就可以让整个流程动起来,让模块和模块之间像齿轮一样咬合,从而保证 client 可以得到一杯正常的茶


那要怎么做呢?


组合

首先明确一点,Bucket(水桶)Kettle(热水壶)Tureen(盖碗) 一定是分属三个模块中的。我们不可能用继承之类的方式把这些方法都封装到一个类簇中,那么我们就必须把他们组合起来,然后再公开某个接口(比如 A方法),以供 client 调用

那么问题就来了,A方法 应该被放在哪个类呢?


方式一:直接组合

由于 Tea(茶)是从Tureen中被产出的,很容易就想到直接在 Tureen 中添加 Bucket 对象和Kettle对象。client 在调用的时候再通过 TureenFactory(盖碗工厂) 来直接创建一个可用的 Tureen 对象,就像这样:
设计模式——1_4 外观(Facade),设计模式,设计模式,外观模式,java

Tureen

//盖碗
public class Tureen {

    //容量
    private final float capacity;
    //当前水量
    private final Water quantity;
    //水桶
    private Bucket bucket;
    //热水壶
    private Kettle kettle;
    //茶叶
    private TeaLeaf teaLeaf;

    public Tureen(float capacity) {
        this.capacity = capacity;
        this.quantity = Water.createEmptyWater();
    }

    public void setBucket(Bucket bucket) {
        this.bucket = bucket;
    }

    public void setKettle(Kettle kettle) {
        this.kettle = kettle;
    }

    //往盖碗里加水
    public boolean addWater(Water water) {
        //检查是否可以容纳,如果足够容纳,则把水全部加入,如果无法容纳则操作失败
        if (capacity - quantity.getQuantity() >= water.getQuantity()) {
            //可以容纳
            quantity.add(water);
            return true;
        }

        return false;//无法容纳
    }

    //生成茶
    public Tea generateTea(float teaQuantity) {
        Water water = bucket.getWater(teaQuantity);//拿到水
        kettle.addWater(water);//加入到热水壶
        kettle.heatUpWater();//加热
        this.addWater(kettle.getWater(teaQuantity));//倒到盖碗中
        return new Tea("这是一份 " + teaLeaf.getType() + " 茶", teaQuantity);
    }

    public TeaLeaf getTeaLeaf() {
        return teaLeaf;
    }

    public void setTeaLeaf(TeaLeaf teaLeaf) {
        this.teaLeaf = teaLeaf;
    }
}

//盖碗工厂
public class TureenFactory {

    public Tureen create(float capacity){
        Tureen tureen = new Tureen(capacity);
        tureen.setBucket(new Bucket(capacity));
        tureen.setKettle(new Kettle(capacity));
        return tureen;
    }
}

在这种方式里 TureenFactory 的存在,可以保证 client 拿到的 Tureen 对象一定可以正常工作。

这个方案现在看起来很美好,我们可以直接通过调用Tureen中的generateTea来保证我们拿到的是一杯可用的茶。但是这是建立在所有提供水的组件对象 都是水桶 和 所有进行加热的组件 都是热水壶的前提下的

你并不能保证这一点,也许将来有人喜欢喝井水,有人喜欢无根之水,还有人喜欢用碳炉煮水而不是热水壶。难道这时候我要让井水、雨水和水桶公用一个父类来方便和盖碗对象组合吗?

这显然是不可能的,所以我们要想想其他组合他们的方法


方法二:外观

让我们回推到最初,其实我们最大的问题,不是如何生成一个可以制作茶水的工具,而是我们需要规范制作一杯茶水的流程。所以我们才不希望 client 直接调用各个模块中的内容

那有没有可能,在底层模块和 client 中间,增加一个 中介层,不要让 client 亲自动手制作茶水,他只需要向 中介对象 发出需要一杯茶的指令,然后就能拿到一杯茶

答案当然是肯定的,就像这样:

设计模式——1_4 外观(Facade),设计模式,设计模式,外观模式,java

public class TeaMaker {

    public Tea getTea(float quantity, TeaLeaf teaLeaf) {
        //创建水桶对象进行供水
        Bucket bucket = new Bucket(quantity, quantity);
        //创建热水壶对象进行加热
        Kettle kettle = new Kettle(quantity);
        kettle.addWater(bucket.getWater(quantity));
        kettle.heatUpWater();
        //创建盖碗对象用于生成茶
        Tureen tureen = new Tureen(quantity);
        tureen.addWater(kettle.getWater(quantity));
        tureen.setTeaLeaf(teaLeaf);
        return tureen.generateTea(quantity);
    }
}

我们通过 TeaMaker 的对象,实现了 client 和底层对象模块之间的分离

  • 如果我们要新增泡茶的流程那么直接修改 TeaMaker 里的内容就可以了(改变的地方被集中到了一处)
  • 如果是有新的底层模块实现加入到程序中,那么我们也可以通过把 TeaMaker 做成一个类簇的方式,来实现不同对底层模块的调用方式

而这正是一个标准的外观模式实现

外观模式并不是简化了多少你的工作,而是把 很可能出现改变的操作都集中到了一处,让你统一修改,统一调用



碎碎念

多个外观对象

对于一个子系统来说,外观对象是可以存在多个的,你可以针对子系统的不同部分创建不同的外观对象


外观和封装

先声明一点,外观模式并不是对底层模块的封装!

你在使用外观模式的同时,依然可以由 client 直接调用底层模块,外观对象只是给你提供了一个简化的调用方式而已,你完全可以无视他,但是要承担这样做的风险


外观和单例

外观对象通常只是一个用来调用子模块的遥控器,所以都是无状态的,因此很多时候都可以是单例的


姑妄言之

外观对象里的内容通常是对一个庞大的子系统的一部分的抽象

这就跟我们每天看到的热搜新闻一样。为什么现在的新闻三天两头就反转,因为很多媒体已经失去了对新闻的严谨性,遇到一件新事,他们看重的是速度,而不能为大众提供事件的全貌,这是不负责任的表现。

一件事只看到一部分和全貌的差别是很大的,这就像盲人摸象,摸到什么就觉得大象是啥样的。上例中的 TeaMaker 是用来沏茶的,但是也许完整的子系统其实是用来煲汤的也说不定,你只是看到了 TeaMaker 而已

所以在这个浮躁的社会里,面对所有新闻都请先别站队,保持独立思考,尽可能让子弹飞一会




万分感谢您看完这篇文章,如果您喜欢这篇文章,欢迎点赞、收藏。还可以通过专栏,查看更多与【设计模式】有关的内容文章来源地址https://www.toymoban.com/news/detail-808100.html

到了这里,关于设计模式——1_4 外观(Facade)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Java 设计模式】结构型之外观模式

    外观模式(Facade Pattern)是一种结构型设计模式, 它为复杂系统提供了一个简化的接口,隐藏了系统的复杂性,使得客户端更容易使用系统 。外观模式通过创建一个包装类(外观类),将系统的复杂性封装起来,对客户端提供一个简单的接口。在本文中,我们将深入研究Ja

    2024年01月21日
    浏览(36)
  • 设计模式-外观模式在Java中的使用示例

    外观模式是一种使用频率非常高的结构型设计模式,它通过引入一个外观角色来简化客户端与子系统 之间的交互,为复杂的子系统调用提供一个统一的入口,降低子系统与客户端的耦合度,且客户端调用非常方便。 示例 自己泡茶和去茶馆喝茶的区别,如果是自己泡茶需要自

    2024年02月17日
    浏览(37)
  • 《golang设计模式》第二部分·结构型模式-05-门面模式Facade)

    门面(Facade)向客户端提供使用子系统的统一接口,用于简化客户端使用子系统的操作。 门面角色(Facade) 客户端可以调用的接口或方法 此角色知晓系统的所有功能和责任 一般情况下,该角色没有实际业务逻辑,只是一个委托类。 子系统角色(Subsystem) 同时有一个或多个

    2024年02月07日
    浏览(48)
  • 【Java面试题】设计模式之七种结构性模式——代理模式、适配器模式、桥接模式、装饰模式、外观模式、享元模式、组合模式

    目录 一、代理模式 二、适配器模式 三、桥接模式 四、装饰模式 五、外观模式 六、享元模式 七、组合模式 概念: 代理模式是为其他对象提供一种以代理控制对这个对象的访问。在某些情况下,一个对象不适合或者不能直接引用另一个对象,而代理对象可以在客户端和目标对

    2023年04月09日
    浏览(42)
  • 设计模式系列-外观模式

    一、上篇回顾 上篇我们主要讲述了创建型模式中的最后一个模式-原型模式,我们主要讲述了原型模式的几类实现方案,和原型模式的应用的场景和特点,原型模式 适合在哪些场景下使用呢?我们先来回顾一下我们上篇讲述的3个常用的场景。 1、我们在运行态的时候,动态的

    2024年02月09日
    浏览(28)
  • 设计模式详解-外观模式

    类型:结构型模式 实现原理:定义了一个高层接口,向现有的系统中的一组接口提供一致的界面 目的:降低访问复杂系统的内部子系统时的复杂度,简化客户端之间的接口,使系统更加容易使用 何时使用:简化复杂系统,方便操作 解决方法:对客户端和系统解耦,让外观类

    2024年02月12日
    浏览(29)
  • 设计模式:外观模式

    外观模式是一种结构型设计模式,它提供了一个统一的接口,用于访问子系统中的一组接口。外观模式隐藏了子系统的复杂性,使得客户端能够更简单地使用子系统的功能。 外观模式的核心思想是将复杂的子系统封装在一个外观类中,客户端只需要与外观类进行交互,而不需

    2024年02月07日
    浏览(36)
  • 设计模式-外观模式

         外观模式(Facade Pattern)是属于结构型的设计模式,它的主要目的是为子系统中的一组接口提供一个统一且更简单的接口,还简化了客户端调用子系统功能的过程。 1 Facade(外观类) : Facade 类提供了对子系统的简洁、一致的接口。它包含了子系统中的多个模块或组件的

    2024年01月19日
    浏览(61)
  • 设计模式之~外观模式

    定义:         为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。 结构图: 区分中介模式: 门面模式对外提供一个接口 中介模式对内提供一个接口 优点: 松耦合:用户与子系统解耦,屏蔽子系统;可以

    2024年02月07日
    浏览(27)
  • 设计模式(8)外观模式

    一、 1、使用背景:降低访问复杂系统的内部子系统时的复杂度,简化客户端之间的接口。 2、定义: 为子系统中的一组接口定义一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。完美地体现了依赖倒转原则和迪米特法则的思想。 3、结构

    2024年02月11日
    浏览(25)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包