结构型模式之外观模式

视频链接地址：https://v.youku.com/v_show/id_XNDYyMzA0MTI3Ng==.html

 

1、外观模式产生的原因：

在软件开发过程中，程序一般会越做越大，而这样系统中类及子系统之间的影响会使彼此间的关系变得错综复杂即过多的耦合，这就导致了随着系统中类或子系统发生变化，与之相关联的子系统或类就需要发生变化。

2、外观模式的定义

外观模式(Facade Pattern)：就是为子系统中的一组接口提供一个统一的高层接口。这一接口使得子系统更加容易使用。

更简单的理解：

通过外观的包装，使客户程序只能看到外观对象而不会看到具体细节对象。从而降低了系统的复杂度，并提高了程序的可维护性。如同黑匣子。

 

 

 举例说明：

为了使用方便，一个电源总开关可以控制两盏灯、一台空调和一台空调的启动和关闭。通过该电源总开关可以同时控制上述所有电器设备，使用外观模式设计该系统。

3、为什么要使用外观模式

没有使用外观模式的时候如下图：

 

 

使用外观模式如下图：

从上面可以看到：使用外观模式之后对程序的易用性和可维护性都是很大的提高。

引入外观模式之后，用户只需要直接与外观角色交互，用户与子系统之间的复杂关系由外观角色来实现，将复杂系统的内部子系统与客户程序之间的依赖解耦，降低了系统的耦合度。

4、外观模式的结构

外观模式包含两个角色：

　　1、Facademic：外观角色

　　外观角色是在客户端直接调用的角色

　　2、SubSystem：子系统角色

　　在软件系统中可以同时有一个或者多个子系统角色

5、外观模式分析

根据“单一职责原则”，在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性。引入一个外观对象，为子系统的访问提供了一个简单而单一的入口。

外观模式也是“迪米特法则”的体现，通过引入一个新的外观类可以降低原有系的复杂度，同时降低客户类与子类系统类的耦合度。

外观模式的目的在于降低系统的复杂程度。

外观模式很大程度上提高了客户端使用的便捷性，使得客户端无须关系子系统的工作细节，通过外观角色即可调用相关功能

6、代码分析

这里我给出了四个Subsystem子系统，分别为A、B、C、D

   public class Facade {
  
      //被委托的对象
      SubSystemA a;
      SubSystemB b;
      SubSystemC c;
      SubSystemD d;
      
      public Facade() {
         a = new SubSystemA();
         b = new SubSystemB();
         c = new SubSystemC();
         d = new SubSystemD();
     }
     
     //提供给外部访问的方法
     public void methodA() {
         this.a.dosomethingA();
     }
     
     public void methodB() {
         this.b.dosomethingB();
     }
     
     public void methodC() {
         this.c.dosomethingC();
     }
    
    public void methodD() {
         this.d.dosomethingD();
     }
     
}

Subsystem子系统角色

　　这里为了不过多赘述，只放上A的代码，其余子系统类似。

 public class SubSystemA {
 
     public void dosomethingA() {
         System.out.println("子系统方法A");
     }
     
 }

Client客户端

 public class Client {
  
      public static void main(String[] args) {
          Facade facade = new Facade();
          
          facade.methodA();
          facade.methodB();
      }
      
 }