阅读 75

门面模式 | 如何提高接口的高可用

532821629127224_.pic.jpg

这是我参与8月更文挑战的第16天,活动详情查看:8月更文挑战

今天我们一起来学习下易于理解的,且常用的一种模式---门面模式。多唠叨几句,我本月将会对java的设计模式精讲,欢迎点击头像,关注我的专栏,我会持续更新,加油!

设计模式之单例模式

设计模式之工厂模式

设计模式之建造者模式

设计模式之代理模式

设计模式之访问者模式

设计模式之适配器模式

设计模式之命令者模式

java状态模式 | 随时随地监控状态改变

java观察者模式 | 如何通知事物的变化

java备忘录模式 | 如何记录历史信息

java迭代器模式模式 | 如何对各个元素进行访问

java享元模式 | 如何共享对象

java解释器模式 | 自定义规则实现逻辑

java桥接模式 | 抽象与不同实现的绑定

java如何通过中间层来解耦

持续更新中......

话不多说,进入正题

门面模式

门面模式更重要的是一种思想,代码设计风格可以多种多样。首先门面模式,比如,我们在回家,肯定有一个大门,院子里有几间屋子,你要进其中的一间屋子,肯定得先进大门,这就是门面。从技术角度,我们理解是网关,像SpringCloud中的gateWay组件。也类似于nginx,是一层门面,所有的流量必须都经过门面。

它的官方定义是:为子系统中的一组接口提供统一的接口。它定义了一个更高级别的接口,使子系统更易于使用。

多么通俗易懂的定义,比如我们微服务当中,有一个工程是专门往外暴露api接口,但是这个服务只是负责组装各个接口,比如这个服务A又去调用B,调用服务C。

下面我们来看下图:

image.png

从该图中可以看到,门面模式包含的关键角色有两个:

  • 门面系统,客户端可以调用这个角色的方法. 此角色知晓子系统的所有功能和责任. 一般情况下, 本角色会将所有从客户端发来的请求委派到相应的子系统去, 也就是说该角色没有实际的业务逻辑, 只是一个委托类

  • 子系统,可以同时有一个或多个子系统. 每一个子系统都不是一个单独的类, 而是一个类的集合.子系统并不知道门面的存在. 对于子系统而言, 门面仅仅是另外一个客户端而已

虽然说门面模式不好用代码去展示,但是我们还是要拿一个场景来说明下

代码展示

比如我们去医院看病,肯定不是直接去其中一个科室,首先去的一个地方就是排队挂号,挂号就是门面,所有的人去看病,必须经过这里,才能去相应的科室

小王因为最近一直加班身体不舒服,头痛,流鼻涕,还发烧,去医院看病。我们分析下,需要去哪几个科室。

首先可能要先去化验科化验下,再去打吊针,最后可能还要去拿药(模拟场景,不要较真)。

//化验科
public class TestOffice {

    //示意方法
    public void test(){
        System.out.println("小王进行化验");
    }
}


//打吊针
public class DripFeeding {

    //示意方法
    public void dripFeeding(){
        System.out.println("小王打吊针");
    }
}


//药房拿药
public class Pharmacy {

    //示意方法
    public void takeDrug(){
        System.out.println("小王来药房拿药");
    }
}

复制代码

上面我们已经把门面模式的子系统列举出来了,下面我们看下门面角色

//医院
public class Hospital {

    //示意方法,满足客户端需要的功能
    public void test(){
        TestOffice a = new TestOffice();
        a.test();
        DripFeeding b = new DripFeeding();
        b.dripFeeding();
        Pharmacy c = new Pharmacy();
        c.takeDrug();
    }
}
复制代码

OK,代码到这里就结束了 ,门面模式,可能是这所有模式里面最容易理解的一种模式。

总结

虽然简单些,但是这里面有很多重要的地方:

门面模式的注意事项:

1.门面不参与子系统内的业务逻辑

门面对象中不要出现具体的业务逻辑代码, 否则就会产生一个倒依赖的问题, 在门面模式中, 门面角色应该是稳定的, 它不应该经常变化, 一个系统一旦投入运行他就不应该被改变, 它是一个系统对外的接口, 变来变去还怎么保证其他模块的稳定运行呢?

如果一定要出现业务处理, 应该建立一个封装类, 封装完毕后提供给门面对象使用.

2.一个子系统可以有多个门面

  • 门面已经庞大到不能忍受的重读. 当一个门面对象过于庞大, 虽然都是非常简单的委托操作, 也建议拆分成多个门面,否则会给以后的维护和扩展带来不必要的麻烦. 按照功能拆分是一个非常好的原则, 比如一个数据库操作的门面可以拆分为增删改查等

总结来说,门面模式在使用的时候能够提供一个简单的概览视图,让使用者能够很方便地去使用。实际上,这一视图对于绝大多数用户来说已经足够了。比如,点击添加商品到购物车、结算、支付、等待收货……虽然对于电商系统本身来说需要考虑各种各样的情况,但是对于用户来说,购物网站这个门面就已经足够他们使用了。

总结来说,门面模式在使用的时候能够提供一个简单的概览视图,让使用者能够很方便地去使用

优点不言而喻,但是缺点我认为,如果子系统太多,容易导致子系统越来越复杂

弦外之音

感谢你的阅读,如果你感觉学到了东西,麻烦您点赞,关注。

我已经将本章收录在专题里,点击下方专题,关注专栏,我会每天发表干货,本月我会持续输入设计模式。

加油! 我们下期再见!

文章分类
后端
文章标签