生活中的设计模式之门面模式

意图

封装子系统的多个不同接口,为客户端提供统一的访问接口,简化客户端对子系统的访问。

背景

如果此刻,你给自己定了"一个亿的小目标",为了实现这个小目标你得先实现第一个小小小目标——注册公司。

注册公司的大概流程是这样:首先,填写各种材料后去工商局办理营业执照;
其次,带上营业执照去刻章处刻制印章;
然后,带上营业执照和印章去银行开户;
最后,带上营业执照、印章、银行账号去税务局核定公司具体税种。这样,公司就算开起来了,就可以光明正大地向一个亿的小目标前进了。

avatar

问题

显然,由于系统(政府)被拆分成很多的子系统(部门),造成某些功能(注册公司)的实现对于客户(创业者)来说非常复杂——需要涉及很多子系统才能完成。
而且,客户类和子系统的接口耦合会导致:如果子系统接口变化,相关的客户类都需要跟着变化。
所以,这时我们应该使用一种简单的方式——门面模式,来简化功能实现的复杂度。

方案

avatar

你的主要职责是如何完成一个亿的目标,而不是把大把精力放在非核心职责上;所以这时你应该请一个助手把这些小事交给他代办,这样的话你就在使用门面模式替自己"偷懒"。

门面模式将客户关心的多个子系统接口封装到一个统一的类即门面类中,使客户端只和门面类交互而不用关心有多少子系统,从而简化了客户使用系统的复杂度。

结构

avatar

客户(Client):子系统的使用者,但不关心子系统的具体实现细节。

门面(Facade):封装了一组子系统的接口,简化客户对子系统的访问。

子系统(Subsystem):指的有很多类构成的集合如:模块、服务、第三方类库等。它是具体的一组功能实现类,客户期望的功能由子系统之间共同协作来实现。

//子系统
public class SubsystemA {

    public void method(){
        System.out.println("subsystemA method");
    }
}
//子系统
public class SubsystemB {

    public void method(){
        System.out.println("SubsystemB method");
    }
}
//子系统
public class SubsystemC {

    public void method(){
        System.out.println("SubsystemC method");
    }
}

//门面
public class Facade {
    protected SubsystemA subsystemA;
    protected SubsystemB subsystemB;
    protected SubsystemC subsystemC;

    public Facade(){
        this.subsystemA = new SubsystemA();
        this.subsystemB = new SubsystemB();
        this.subsystemC = new SubsystemC();
    }

    public void simpleMethodA(){
        subsystemA.method();
        subsystemB.method();
    }

    public void simpleMethodB(){
        subsystemA.method();
        subsystemB.method();
        subsystemC.method();
    }
}

public class Client {
    
    public static void main(String[] args){
        Facade facade = new Facade();
        //调用门面封装好的方法A
        facade.simpleMethodA();

    }
}

应用

现在,互联网公司的系统架构大多都会采用微服务架构——将整个系统拆分为多个能独立的运行的子系统或者说服务。
比如说电商系统,一般可以拆分为订单、支付、商品、促销、库存等等服务。
但是拆分后,有些功能就需要各个子系统之间彼此协作才能完成;比如商品支付之前的下单功能,它需要创建订单并放回支付信息。

假设,我们有一个订购商品的控制器(OrderGoodsController),它代表客户端;还有下面这些服务,它们代表子系统。

库存服务(InventoryService):检查订购的商品库存是否足够。

public class InventoryService {

    public boolean check(String goodsId){
        return true;
    }
}

商品服务(GoodsService):为创建订单提供所需的商品信息。


public class GoodsService {

    public String getGoods(String goodsId){
        return "goods";
    }
}

促销服务(CouponService):商品的优惠信息。


public class CouponService {

    public String getCoupon(String goodsId){
        return "coupon";
    }
}

支付服务(PaymentService):核算商品支付金额并生成签名。


public class PaymentService {

    public String getPayment(String goods,String coupon){
        return "payment";
    }
}

订单服务(OrderService):记录用户下单时商品、优惠券、支付等信息。


public class OrderService {

    public String createOrder(String goods,String coupon,String payment){
        return "order";
    }
}

如果,我们让客户端(OrderGoodsController)自行和上面的服务交互的话,那么整个客户端的逻辑就变得很复杂。


public class OrderGoodsController {
    
    public void orderGoods(){
        String goodsId = "goodsId";
        //检查商品库存
        if(inventoryService.check(goodsId)){
           //获取商品信息
           String goods = goodsService.getGoods(goodsId);
           //获取商品优惠信息
           String coupon = couponService.getCoupon(goodsId);
           //核算金额并获取支付信息
           String payment = paymentService.getPayment(goods,coupon);
           //创建订单
           String order = orderService.createOrder(goods, coupon,payment);
        }
    }
}


所以,这个时候我们可以创建一个下单门面服务类PlaceOrderFacade,将下单的任务全权委托给它。如下:



public class PlaceOrderFacade {
    
    public String placeOrder(String goodsId){

        //检查商品库存
        if(inventoryService.check(goodsId)){
           //获取商品信息
           String goods = goodsService.getGoods(goodsId);
           //获取商品优惠信息
           String coupon = couponService.getCoupon(goodsId);
           //核算金额并获取支付信息
           String payment = paymentService.getPayment(goods,coupon);
           //创建订单
           String order = orderService.createOrder(goods, coupon,payment);
           
           return payment;
        }


    }
}

这样,所有的客户端都只需要依赖下单门面类,就可以创建订单并获取支付信息了,同时隐藏了子系统的复杂性以及功能可以被复用。


public class OrderGoodsController {

    public void orderGoods(){
        String goodsId = "goodsId";
        placeOrderFacade.placeOrder(goodsId);
    }

}



扩展阅读

架构设计思维篇之结构

架构设计思维篇之概念

架构设计容错篇之重试

架构设计容错篇之熔断

架构设计容错篇之限流

架构设计事务篇之Mysql事务原理

架构设计事务篇之CAP定理

架构设计事务篇之分布式事务

架构设计消息篇之消息丢失

架构设计消息篇之保证消息顺序性

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,470评论 6 501
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,393评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,577评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,176评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,189评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,155评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,041评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,903评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,319评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,539评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,703评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,417评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,013评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,664评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,818评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,711评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,601评论 2 353

推荐阅读更多精彩内容