设计模式——门面模式

设计模式——门面模式 | 外观模式

news2024/11/19 20:42:26

在这里插入图片描述

哈喽，各位盆友们！我是你们亲爱的学徒小z，今天给大家分享的文章是设计模式的——门面模式。

文章目录

定义
通用类图
- 1.通用结构
- 2.优点
- 3.缺点
使用场景
注意事项
- 1.一个子系统可以有多个门面
- 2.门面不参与子系统内的业务逻辑

定义

定义：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

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

通用类图

1.通用结构

Facade门面角色

客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。
subsystem子系统角色

可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。

通用代码

//子系统
public class ClassA {
    public void doSomethingA(){
    //业务逻辑
    }
}
public class ClassB {
    public void doSomethingB(){
    //业务逻辑
    }
}
public class ClassC {
    public void doSomethingC(){
    //业务逻辑
    }
}

//门面对象
public class Facade {
    //被委托的对象
    private ClassA a = new ClassA();
    private ClassB b = new ClassB();
    private ClassC c = new ClassC();
    //提供给外部访问的方法
    public void methodA(){
    	this.a.doSomethingA();
    }
    public void methodB(){
        this.b.doSomethingB();
    }
    public void methodC(){
        this.c.doSomethingC();
    }
}

2.优点

减少系统之间的相互依赖：客户端与子系统之间的依赖减少
提高了灵活性
提高了安全性

3.缺点

违反了开闭原则：对子系统的修改可能需要对门面类进行相应的修改

使用场景

为一个复杂的模块或子系统提供一个供外界访问的接口
子系统相对独立——外界对子系统的访问只要黑箱操作即可

注意事项

1.一个子系统可以有多个门面

适用条件
门面已经庞大到不能忍受的程度
子系统可以提供不同访问路径

以门面模式的通用源代码为例。ClassA、ClassB、ClassC是一个子系统的中3个对象，现在有两个不同的高层模块来访问该子系统，模块一可以完整的访问所有业务逻辑，也就是通用代码中的Facade类，它是子系统的信任模块；而模块二属于受限访问对象，只能访问methodB方法。

处理方法：需要建立两个门面以供不同的高层模块来访问，在原有的通用源码上增加一个新的门面
```
//新增门面
public class Facade2 {
    //引用原有的门面
    private Facade facade = new Facade();
    //对外提供唯一的访问子系统的方法
    public void methodB(){
    	this.facade.methodB();
    }
}
```
增加的门面非常简单，委托给了已经存在的门面对象Facade进行处理，为什么要使用委托而不再编写一个委托到子系统的方法呢？那是因为在面向对象的编程中，尽量保持相同的代码只编写一遍，避免以后到处修改相似代码出现问题

2.门面不参与子系统内的业务逻辑

举例说明

我们把门面上的methodC上的逻辑修改一下，它必须先调用ClassA的doSomethingA方法，然后再调用ClassC的doSomethingC方法

//修改门面
public class Facade {
    //被委托的对象
    private ClassA a = new ClassA();
    private ClassB b = new ClassB();
    private ClassC c = new ClassC();
    //提供给外部访问的方法
    public void methodA(){
    	this.a.doSomethingA();
    }
    public void methodB(){
    	this.b.doSomethingB();
    }
    public void methodC(){
        this.a.doSomethingA();
        this.c.doSomethingC();
    }
}

这样的设计不靠谱。因为已经让门面对象参与了业务逻辑，门面对象只是提供一个访问子系统的一个路径而已，它不应该也不能参与具体的业务逻辑，否则就会产生一个倒依赖的问题：子系统必须依赖门面才能被访问，这是设计上一个严重错误，不仅违反了单一职责原则，同时也破坏了系统的封装性

解决方法

建立一个封装类，封装完毕后提供给门面对象

//封装类
public class Context {
    //委托处理
    private ClassA a = new ClassA();
    private ClassC c = new ClassC();
    //复杂的计算
    public void complexMethod(){
        this.a.doSomethingA();
        this.c.doSomethingC();
    }
}

//门面类
public class Facade {
    //被委托的对象
    private ClassA a = new ClassA();
    private ClassB b = new ClassB();
    private Context context = new Context();
    //提供给外部访问的方法
    public void methodA(){
    	this.a.doSomethingA();
    }
    public void methodB(){
    	this.b.doSomethingB();
    }
    public void methodC(){
    	this.context.complexMethod();
    }
}

该封装类的作用就是产生一个业务规则complexMethod，并且它的生存环境是在子系统内，仅仅依赖两个相关的对象，门面对象通过对它的访问完成一个复杂的业务逻辑
通过这样一次封装后，门面对象又不参与业务逻辑了，在门面模式中，门面角色应该是稳定，它不应该经常变化，一个系统一旦投入运行它就不应该被改变，因为它是一个系统对外的接口。