【Go-设计模式】外观模式 详解

概念：

1. 外观模式(Facade)，也叫 “门面模式/过程模式”：
   外观模式为 子系统 中的 一组接口 提供一个 一致的界面，此模式定义了一个 高层接口，这个接口使得这一子系统更加容易使用
2. 外观模式 通过定义一个 一致的接口，用以屏蔽 内部子系统的细节，使得 调用端 只需跟这个接口发生调用，而 无需关心 这个子系统的 内部细节

---

UML：

• 外观类(Facade)：
  为 调用端 提供 统一的调用接口，外观类 知道 哪些子系统 负责 处理请求，从而将 调用端的请求 代理给 适当子系统对象
• 调用者(Client)：
  外观接口的 调用者
• 子系统的集合：
  模块 或者 子系统，处理 Facade对象指派的任务，是功能的 实际提供者

---

示例：

子系统类：

子系统类1：

type ModelA struct {
}

func (this ModelA) FuncA() string {
	return "FunA worked!"
}

---

子系统类2：

type ModelB struct {
}

func (this ModelB) FuncB() string {
	return "FunB worked!"
}

---

外观类：

type FacadeApi struct {
	modelA ModelA
	modelB ModelB
}

func NewFacadeApi() FacadeApi {
	return FacadeApi{
		modelA: ModelA{},
		modelB: ModelB{},
	}
}

func (this FacadeApi) FuncApi() string {
	resultA := this.modelA.FuncA()
	resultB := this.modelB.FuncB()
	return "执行步骤为：\n" + resultA + "\n" + resultB
}

---

测试：

package main

import (
	"DemoProject/design/base23"	// 根据自己的项目路径定制
	"fmt"
)

func main() {
	// facade
	client := base23.NewFacadeApi()
	result := client.FuncApi()
	fmt.Println(result)
}

---

注意事项：

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