模式定义
-
外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。
-
这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。
模式结构
外观模式包含以下几个主要角色：
-
- 外观（Facade）:
- 提供一个简化的接口，封装了系统的复杂性。外观模式的客户端通过与外观对象交互，而无需直接与系统的各个组件打交道。
- 外观（Facade）:
- 子系统（Subsystem）:
- 由多个相互关联的类组成，负责系统的具体功能。外观对象通过调用这些子系统来完成客户端的请求。
- 客户端（Client）:
- 使用外观对象来与系统交互，而不需要了解系统内部的具体实现。
模式优点
- 减少依赖：客户端与子系统之间的依赖减少。
- 提高灵活性：子系统的内部变化不会影响客户端。
- 增强安全性：隐藏了子系统的内部实现，只暴露必要的操作。
模式缺点
- 违反开闭原则：对子系统的修改可能需要对外观类进行相应的修改。
使用场景
- 当客户端不需要了解系统内部的复杂逻辑和组件交互时。
- 当需要为整个系统定义一个清晰的入口点时。
应用实例
- Java的MVC架构：通过外观模式，可以简化对表示层、业务逻辑层和数据访问层的访问。
示例代码
package practise
import "fmt"
/*
外观模式
*/
// 相当于MVC中的controller，暴露出来一个api接口，使用该接口调用不同service层的方法，相当于外观。
type API interface {
Test() string
}
func NewAPI() API {
return &apiTmpl{
a: NewAModuleAPI(),
b: NewBModuleAPI(),
}
}
type apiTmpl struct {
a AModuleAPI
b BModuleAPI
}
func (a *apiTmpl) Test() string {
aString := a.a.TestA()
bString := a.b.TestB()
return fmt.Sprintf("\na:%s\nb:%s", aString, bString)
}
// AModuleAPI 和 BModuleAPI 相当于service层不同的api，例如用户api、文章api
type AModuleAPI interface {
TestA() string
}
type BModuleAPI interface {
TestB() string
}
type aModule struct{}
type bModule struct{}
func (a *aModule) TestA() string {
return "a module"
}
func (b *bModule) TestB() string {
return "b module"
}
func NewAModuleAPI() AModuleAPI {
return &aModule{}
}
func NewBModuleAPI() BModuleAPI {
return &bModule{}
}
package main
import (
"fmt"
"practise/practise"
)
func main() {
api := practise.NewAPI()
fmt.Println("result:", api.Test())
}