Golang设计模式——03外观模式

简介: Golang设计模式——03外观模式

外观模式

优点

外观模式(Facade Pattern)也称为过程模式,是结构性模式。外观模式为子系统的一组接口提供了一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。外观模式可以理解为转换一群接口,客户只要调用这一个接口而不用调用多个接口才能达到目的,也不需关心这个子系统的内部细节。就是解决多个复杂接口带来的使用困难,起到简化用户操作的作用。

  1. 外观模式对客户端与子系统的耦合关系,让子系统内部的模块更易维护和扩展。
  2. 外观模式对外屏蔽了子系统的细节,因此外观模式降低了客户端对子系统使用的复杂性。
  3. 当系统需要进行分层设计时,可以考虑外观模式帮我们更好的划分访问的层次。
  4. 在维护一个遗留的大型系统时,可能这个系统已经变得非常难以维护和扩展,此时可以考虑为新系统开发一个Facade类,来提供遗留系统的比较清晰简单的接口,让新系统与Facade类交互,提高复用性。

在软件开发中,有时候一个客户类需要和多个业务类交互,由于涉及到的类比较多,导致使用时代码较为复杂,此时,特别需要一个能够统筹所有业务类的角色,由它来负责和业务类进行交互,而客户类只需与该类交互。外观模式通过引入一个新的外观类(Facade)来实现该功能,它为多个业务类的调用提供了一个统一的入口,简化了类与类之间的交互。

缺点

  1. 不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
  2. 如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开闭原则。

场景

  1. 为一个复杂的模块或子系统提供一个供外界访问的接口

代码

package Facade
import "fmt"
type CarModel struct {
}
func NewCarModel() *CarModel {
  return &CarModel{}
}
func (c *CarModel) SetModel() {
  fmt.Println("CarModel - SetModel")
}
func (c *CarModel) ModelBroke() {
  fmt.Println("Model was Broke")
}
type CarEngine struct {
}
func NewCarEngine() *CarEngine {
  return &CarEngine{}
}
func (c *CarEngine) SetEngine() {
  fmt.Println("CarEngine - SetEngine")
}
func (c *CarEngine) EngineBroke() {
  fmt.Println("Engine was Broke")
}
type CarBody struct {
}
func NewCarBody() *CarBody {
  return &CarBody{}
}
func (c *CarBody) SetCarBody() {
  fmt.Println("CarBody - SetBody")
}
func (c *CarBody) BodyBroke() {
  fmt.Println("Body was Broke")
}
type CarFacade struct {
  model  CarModel
  engine CarEngine
  body   CarBody
}
func NewCarFacade() *CarFacade {
  return &CarFacade{
    model:  CarModel{},
    engine: CarEngine{},
    body:   CarBody{},
  }
}
func (c *CarFacade) CreateCompleteCar() {
  c.model.SetModel()
  c.body.SetCarBody()
  c.engine.SetEngine()
}
func (c *CarFacade) MethodA() {
  c.model.SetModel()
  c.body.BodyBroke()
  c.engine.SetEngine()
  c.model.ModelBroke()
}
func (c *CarFacade) MethodB() {
  c.model.ModelBroke()
  c.body.BodyBroke()
  c.engine.EngineBroke()
}
package Facade
import "testing"
func TestCarFacade_CreateCompleteCar(t *testing.T) {
  car:=NewCarFacade()
  car.CreateCompleteCar()
  car.MethodA()
  car.MethodB()
}

其他设计模式

设计模式Git源代码

00简单工厂模式

01工厂方法模式

02抽象工厂模式

03外观模式

04建造者模式

05桥接模式

06命令模式

07迭代器模式

08模板模式

09访问者模式

10备忘录模式

11责任链模式

12中介模式

13原型模式

14状态模式

15策略模式

16享元模式

17组合模式

18解释器模式

19单例模式

20适配器模式

21代理模式

22装饰器模式

23观察者模式


目录
相关文章
|
8月前
|
设计模式 API 数据安全/隐私保护
探索设计模式的魅力:外观模式简化术-隐藏复杂性,提供简洁接口的设计秘密
外观模式是一种关键的设计模式,旨在通过提供一个简洁的接口来简化复杂子系统的访问。其核心价值在于将复杂的内部实现细节封装起来,仅通过一个统一的外观对象与客户端交互,从而降低了系统的使用难度和耦合度。在软件开发中,外观模式的重要性不言而喻。它不仅能够提高代码的可读性、可维护性和可扩展性,还能促进团队间的协作和沟通。此外,随着业务需求和技术的发展,外观模式能够适应变化,通过修改外观对象来灵活调整客户端与子系统之间的交互方式。总之,外观模式在软件设计中扮演着举足轻重的角色,是构建高效、稳定且易于维护的软件系统的关键
202 1
探索设计模式的魅力:外观模式简化术-隐藏复杂性,提供简洁接口的设计秘密
|
8月前
|
设计模式 Java
23种设计模式,外观模式的概念优缺点以及JAVA代码举例
【4月更文挑战第6天】外观模式(Facade Pattern)是一种使用频率非常高的结构型设计模式,其核心思想是为子系统中的一组接口提供一个一致的界面。外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。简而言之,外观模式就是客户端与复杂子系统之间的一个简单而统一的接口
91 3
|
8月前
|
设计模式 存储 uml
C++ 设计模式实战:外观模式和访问者模式的结合使用,派生类访问基类的私有子系统
C++ 设计模式实战:外观模式和访问者模式的结合使用,派生类访问基类的私有子系统
78 1
|
2天前
|
设计模式 缓存 应用服务中间件
「全网最细 + 实战源码案例」设计模式——外观模式
外观模式(Facade Pattern)是一种结构型设计模式,旨在为复杂的子系统提供一个统一且简化的接口。通过封装多个子系统的复杂性,外观模式使外部调用更加简单、易用。例如,在智能家居系统中,外观类可以同时控制空调、灯光和电视的开关,而用户只需发出一个指令即可。
97 69
|
4月前
|
设计模式 Java
Java设计模式-外观模式(11)
Java设计模式-外观模式(11)
|
3月前
|
设计模式 Java
Java设计模式之外观模式
这篇文章详细解释了Java设计模式之外观模式的原理及其应用场景,并通过具体代码示例展示了如何通过外观模式简化子系统的使用。
36 0
|
5月前
|
设计模式 存储 Java
【九】设计模式~~~结构型模式~~~外观模式(Java)
文章详细介绍了外观模式(Facade Pattern),这是一种对象结构型模式,通过引入一个外观类来简化客户端与多个子系统之间的交互,降低系统的耦合度,并提供一个统一的高层接口来使用子系统。通过文件加密模块的实例,展示了外观模式的动机、定义、结构、优点、缺点以及适用场景,并讨论了如何通过引入抽象外观类来提高系统的可扩展性。
【九】设计模式~~~结构型模式~~~外观模式(Java)
|
6月前
|
设计模式 JavaScript 前端开发
js设计模式【详解】—— 外观模式
js设计模式【详解】—— 外观模式
49 2
|
8月前
|
设计模式
设计模式-外观模式
设计模式-外观模式
64 0
|
7月前
|
设计模式 Java
Java设计模式:外观模式之优雅门面(九)
Java设计模式:外观模式之优雅门面(九)