设计模式之外观模式

今天我们分享的是外观模式

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

 

 

目的：

在软件系统开发的过程中，当组件的客户（即外部接口，或客户程序）和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。

依赖颠倒原则和迪米特法则

 

外观模式包含如下两个角色：
（1）、外观角色（Facade）：在客户端可以调用它的方法，在外观角色中可以知道相关的（一个或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。

（2）、子系统角色（SubSystem）：在软件系统中可以有一个或者多个子系统角色，每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

 

外观模式的优点：

外观模式对客户屏蔽了子系统组件，从而简化了接口，减少了客户处理的对象数目并使得子系统的使用更简单

实现了子系统与客户之间的松耦合关系，而子系统内部功能组件是紧耦合。

缺点：

如果增加新的子系统可能需要修改外观类或客户端的源代码，违背了开---闭原则

 

例如：

我们玩的游戏：

有技能，装备，经脉效果

外观类：人物

使用技能1：

附加装备效果

附加经脉加成

使用技能1

 

 

使用技能2：

附加装备效果

附加经脉效果

使用技能2

 

客户端调用：

人物使用技能1

人物使用技能2

 

使用环境：

构建一个有层次结构的子系统时，使用外观模式定义子系统中每层的入口点，如果子系统之间是相互依赖的，则可以让他们通过外观接口进行通信，减少子系统之间的依赖关系。

子系统往往会因为不断的重构演化而变得越来越复杂，大多数的模式使用时也会产生很多很小的类，这给外部调用他们的用户程序带来了使用的困难，我们可以使用外观类提供一个简单的接口，对外隐藏子系统的具体实现并隔离变化。

当维护一个遗留的大型系统时，可能这个系统已经非常难以维护和拓展，但因为它含有重要的功能，新的需求必须依赖于它，则可以使用外观类，来为设计粗糙或者复杂的遗留代码提供一个简单的接口，让新系统和外观类交互，而外观类负责与遗留的代码进行交互。