设计模式-结构型设计模式-2.外观模式(php)

本文介绍了外观模式,它属于结构型设计模式,目的是隐藏系统复杂性,提供简单访问接口。阐述了其UML结构,指出优秀的Facade无new且构造参数为接口类型。还说明了应用场景,如构建子系统、子系统变复杂、维护遗留系统时使用。同时分析了优缺点,并给出git地址。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

设计模式类型

结构型设计模式

设计模式名称

外观模式

模式定义

外观模式(Façade Pattern)属于类的结构型模式,目的是隐藏系统的复杂性,并向客户端提供了一个简单的可以访问系统的接口。

UML

Façade通过嵌入多个(或者一个)接口来解耦访客与子系统。
1、Façade不会禁止客户端访问子系统
2、可以为子系统提供多个Facade
因此一个好的 Facade 里面不会有 new 。如果每个方法里都要构造多个对象,那么它就不是 Facade,而是生成器或者[抽象|静态|简单] 工厂 [方法]。
优秀的 Facade 不会有 new,并且构造函数参数是接口类型的。如果你需要创建一个新实例,则在参数中传入一个工厂对象。
在这里插入图片描述

应用场景

1、构建一个有层次结构的子系统时,使用外观模式定义子系统中每层的入口点,如果子系统之间是互相依赖的,则可以通过外面模式接口让他们之间通信,减少子系统的依赖关系。
2、子系统随着业务需求/重构变得越来约复杂时,会产生很多很小的类,这样外部客户端的调用也将变得复杂,这时使用外观模类提供一个简单的接口,对外隐藏子系统的具体运行过程并隔离变化。
3、维护一个遗留的大型系统时,可能这个系统已经难以扩展,但因为它含有重要的功能,新的需求必须依赖与它,这时我们可以使用外观类,来为原来设计粗糙或者复杂的遗留代码提供一个简单的接口,让新系统和外观类交互,而外观类负责与原系统交互

优缺点

优点

1、实现了子系统与客户端直击爱你的松耦合关系
2、对于客户端屏蔽了子系统组件,减少了客户端所处理对象的数目,减少使用的复杂性

缺点

1、子系统变更时,Façade类需要修改,不符合开放封闭原则,且Façade类不好扩展

git地址

https://github.com/wonlon/Design-patterns

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值