golang设计模式（10）外观模式

超、凢脫俗 2022-06-06 00:08 145阅读 0赞

**外观模式意图**  
外观模式为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得子系统更加容易使用。

**外观模式动机**  
将一个系统划分为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统的通信和相互依赖关系达到最小。达到该目标的途径之一就是引入一个外观对象，它为子系统中较为一般的设施提供了一个单一而简单的界面。

**外观模式适用性**  
遇到以下情况使用外观模式：  
1）当要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用都会产生更多更小的类。这使得子系统更具有可重用性，也更容易对子系统进行定制，但也给那些不需要定制的子系统的用户甙类一些使用上的困难。  
2）客户程序与抽象类的实现部分之间存在着很大的依赖性。引入外观类将使这个子系统以及其他的子系统分离，可以提高子系统的独立性和可移植性。  
3）当你需要构建一个层次结构的子系统时，使用外观模式定义子系统中每层的入口点。如果子系统见是相互依赖的，可以让它们仅仅通过外观进行通讯，从而简化了它们之间的依赖关系。

**外观模式结构**  
![外观模式uml][uml]

**外观模式效果**  
外观模式有下面一些优点：  
1）它对客户屏蔽子系统组件，因而减少了客户处理对象的数目并使得子系统使用起来更加方便。  
2）它实现了子系统与客户之间的松耦合关系，二子系统内部的功能组件往往是紧耦合的。松耦合关系使得子系统的组件变化不会影响到它的客户。有利于建立层次结构系统，也有助于对对象之间的依赖关系分层。外观模式可以消除复制的循环依赖关系。这一点在客户程序与子系统是分别实现的时候尤为重要。在大型软件系统中降低编译依赖关系至关重要。在子系统类改变时，希望尽量减少重编译工作以节省时间。用外观模式可以降低编译依赖性，限制重要系统中较小的变化所需的重编译工作。

缺点：  
1）不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。  
2）在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”

**实现**

package main
    
    import (
     "fmt"
    )
    
    type DataHandler struct {
        decoder *Decoder     //解码子系统
        handler *MainHandler //处理子系统
        encoder *Encoder     //编码子系统
    }
    
    func (pD *DataHandler) Working() {
        pD.decoder.Working()
        pD.handler.Working()
        pD.encoder.Working()
    }
    
    type Decoder struct {
    }
    
    func (pD *Decoder) Working() {
        fmt.Println("解码子系统先XXX格式数据,并转换为xxxx结构数据")
    }
    
    type MainHandler struct {
    }
    
    func (pM *MainHandler) Working() {
        fmt.Println("数据处理子系统，处理数据")
    }
    
    type Encoder struct {
    }
    
    func (pE *Encoder) Working() {
        fmt.Println("编码子系统将xxx数据格式转换为Json格式")
    }
    
    func main() {
    
        worker := &DataHandler{decoder: &Decoder{}, handler: &MainHandler{}, encoder: &Encoder{}}
        worker.Working()
        return
    }

运行结果：

解码子系统先XXX格式数据,并转换为xxxx结构数据
    数据处理子系统，处理数据
    编码子系统将xxx数据格式转换为Json格式

[uml]: /images/20220606/3d051b45b2da47769f3ec827163b64ca.png