设计模式——外观模式

什么是外观模式

通过引入一个外观类，将子系统与客户端分割，使客户端与子系统解耦

 

外观模式的角色

 

Facade: 外观角色

SubSystem:子系统角色

 

 

实例：

假设有CPU、磁盘、内存三个子系统，客户端通过三个子系统的协调工作来运行自己的代码：

CPU：

public class CPU {
    
    public void start(){
        System.out.println("CPU计算数据");
    }
    
    public void close(){
        System.out.println("CPU计算数据完毕");
    }
    
}

 

Disk：

public class Disk {
    
    public void writeToDisk(){
        System.out.println("写入数据到磁盘");
    }
    
}

 

Memory：

public class Memory {  
    public void write(){
        System.out.println("写入数据到内存");
    }
    
}

 

Facade：

public class Facade {
    
    private CPU c=new CPU();
    private Disk d=new Disk();
    private Memory m=new Memory();
    
    public void  Operate(){
        c.start();
        m.write();
        c.close();
        d.writeToDisk();
    }
    
}

 

main：

public class main {
      public static void main(String[] args){
          Facade fa=new Facade();
          fa.Operate();
      }
}

执行结果：

 

外观模式的一点思考

外观模式通过外观类可以实现如下效果：

1、向客户端隐藏了子系统工作的细节，同时减少了客户端需要编写的代码（客户端不需要自己协调子系统的工作）

2、外观类的作用是连接子系统与客户端，并不负责子系统功能的扩展，因此，不能通过让外观类继承某些类来实现子系统功能的扩展（此时外观类除上述功能外，又增加了子系统的扩展，职责有些许混乱），子系统功能的扩展应该通过修改子系统的代码或是增加新的子系统来完成

3、外观模式本身不能很好的满足开闭原则，当有新的子系统加入或是移除旧的子系统时，可能就要修改客户端与外观类的代码，可以通过引入抽象外观类来解决这个弊端，拿Spring IOC来举个例子，假设抽象外观类为A，它有一个外观实现类B，bean C有一个类型为A的属性，目前依赖注入的是B，现在我们想扩展子系统的功能，我们实现另一个外观实现类D，此时只要修改配置文件，让D依赖注入到C即可，不需要修改任何现有代码，如果我们不使用抽象外观类A，那么就需要更改bean C中的属性的类型，改一处可能就会处处改。