当前位置: 首页 > article >正文

23种设计模式(10)——门面模式

门面模式(Facade Pattern)又叫作外观模式,提供了一个统一的接口,用来访问子系统中的一群接口。其主要特征是定义了一个高层接口,让子系统更容易使用,属于结构型设计模式。

其实,在日常编码工作中,我们都在有意无意地大量使用门面模式。但凡只要高层模块需要调度多个子系统(2个以上类对象),我们都会自觉地创建一个新类封装这些子系统,提供精简的接口,让高层模块可以更加容易地间接调用这些子系统的功能。

来个简单的demo:

我u有以下三个service:

public class ServiceA { 
    public void doA(){ 
        System.out.println("do ServiceA"); 
    } 
} 
public class ServiceB { 
    public void doB(){ 
        System.out.println("do ServiceB"); 
    } 
} 
 
public class ServiceC { 
    public void doC(){ 
        System.out.println("do ServiceC"); 
    } 
} 

在没有引入门面模式的时候,我们是这么调用的:

public class Client { 
    public static void main(String[] args) { 
        ServiceA serviceA = new ServiceA(); 
        ServiceB serviceB = new ServiceB(); 
        ServiceC serviceC = new ServiceC(); 
 
        serviceA.doA(); 
        serviceB.doB(); 
        serviceC.doC(); 
    } 
} 

没啥毛病啊,结合到spingmvc开发,这些service交给spring管理,根本不用自己new了,直接注入到controller就可以,但是如果10个地方都用了这三个service呢?这10个controller里都注入一下?这时候考虑优化——我可以新建一个service,持有这个三个service不就ok了吗:

public class ServiceFacade { 
    //是不是很像我们controller里注入各种service? 
    private ServiceA serviceA = new ServiceA(); 
    private ServiceB serviceB = new ServiceB(); 
    private ServiceC serviceC = new ServiceC(); 
 
    public void doA() { 
        serviceA.doA(); 
    } 
 
    public void doB() { 
        serviceB.doB(); 
    } 
 
    public void doC() { 
        serviceC.doC(); 
    } 
} 

客户端就变成了

public class Client { 
    public static void main(String[] args) { 
        //轻轻松松的搞定,只需要创建门面这个对象即可 
        ServiceFacade serviceFacade= new ServiceFacade (); 
        serviceFacade.doA(); 
        serviceFacade.doB(); 
        serviceFacade.doC(); 
    } 
} 

门面模式中的角色

由上图可以看到,门面模式主要包含2个角色。

  • 外观角色(Facade):也叫作门面角色,是系统对外的统一接口。
  • 子系统角色(Service):可以同时有一个或多个Service。每个Service都不是一个单独的类,而是一个类的集合。Service们并不知道Facade的存在,对于Service们而言,Facade 只是另一个客户端而已(即Facade对ServiceA、ServiceB、ServiceC透明)。

门面模式的扩展

优点

● 减少系统的相互依赖   想想看,如果我们不使用门面模式,外界访问直接深入到子系统内部,相互之间是一种强耦合关系,你死我就死,你活我才能活,这样的强依赖是系统设计所不能接受的,门面模式的出现就很好地解决了该问题,所有的依赖都是对门面对象的依赖,与子系统无关。

● 提高了灵活性   依赖减少了,灵活性自然提高了。不管子系统内部如何变化,只要不影响到门面对象,任你自由活动。

● 提高安全性   想让你访问子系统的哪些业务就开通哪些逻辑,不在门面上开通的方法,你休想访问到 。

缺点

当增加子系统和扩展子系统行为时,可能容易带来未知风险。

不符合开闭原则。

某些情况下,可能违背单一职责原则。


http://www.kler.cn/news/107790.html

相关文章:

  • css:如何通过不同的值,改变盒子的样式和字体颜色通过computed而不是v-if
  • Operator开发之operator-sdk入门
  • XMLHttpRequest拦截请求和响应
  • Unity性能优化一本通
  • YOLOv5 onnx \tensorrt 推理
  • uniapp接口请求api封装,规范化调用
  • Go 实现插入排序算法及优化
  • 软考系列(系统架构师)- 2013年系统架构师软考案例分析考点
  • 5月22日比特币披萨日,今天你吃披萨了吗?
  • 【计算机网络】认识协议
  • Spring Boot拓展XML格式的请求和响应
  • 『Jmeter入门万字长文』 | 从环境搭建、脚本设计、执行步骤到生成监控报告完整过程
  • leetCode 229. 多数元素 II + 摩尔投票法 + 进阶 + 优化空间
  • Linux:【1】Linux中的文件权限概念和相关命令
  • Hive 视图和索引
  • Spring Security—配置(Configuration)
  • 命令行参数、环境变量
  • 集合总结(Java)
  • JavaScript_Pig Game切换当前玩家
  • 【Linux】权限完结
  • 从lc560“和为 K 的子数组“带你认识“前缀和+哈希表“的解题思路
  • 【iPad已停用】解锁教程
  • 现代挖掘机vr在线互动展示厅是实现业务增长的加速度
  • Java集合-HashMap源码分析
  • Docker多平台、跨平台编译打包
  • 【ChatGPT系列】ChatGPT:创新工具还是失业威胁?
  • spark3.3.x处理excel数据
  • 【Python机器学习】零基础掌握RandomForestClassifier集成学习
  • 小程序原生开发中的onLoad和onShow
  • Games104现代游戏引擎笔记 网络游戏进阶架构