【golang设计模式】—— 外观模式

模式定义

• 外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。

• 这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。

模式结构

外观模式包含以下几个主要角色：

• 外观（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())

}