外观模式

最新推荐文章于 2023-05-27 16:35:30 发布

原创最新推荐文章于 2023-05-27 16:35:30 发布 · 636 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#设计模式

设计模式专栏收录该内容

38 篇文章

订阅专栏

外观模式

外观模式是一种使用频率非常高的结构型设计模式,它通过引入一个外观角色来简化客户端与子系统之间的交互,为复杂的子系统调用提供一个统一的入口,使子系统与客户端的耦合度降低,且客户端调用非常方便.

外观模式概述

外观模式引入一个新的外观类,它为多个业务类的调用提供了一个统一的入口,简化了类与类之间的交互.在外观模式中,那些需要交互的业务类被称为子系统.

在外观模式中,一个子系统的外部与其内部的通信通过一个统一的外观类进行,外观类将客户类与子系统的内部复杂性分隔开,使得客户类只需要与外观角色打交道,而不需要与子系统内部的很多对象打交道.

外观模式:为子系统中的一组接口提供一个统一的入口.外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用.

外观模式又称为门面模式,它是一种对象结构型模式.外观模式是迪米特法则的一种具体实现.

外观模式结构

外观模式没有一个一般化的类图描述.

外观模式包含2个角色:

外观角色.
子系统角色.

外观模式实现

在引入外观模式之后,增加新的子系统或者移除子系统都非常方便,客户类无须进行修改(或者极少的修改),只需要在外观类中增加或移除对子系统的引用即可.

子系统类

public class SubSystemA{
    public void methodA(){
        //业务实现代码
    }

}

public class SubSystemB{
    public void methodB(){
        //业务实现代码
    }

}

public class SubSystemC{
    public void methodC(){
        //业务实现代码
    }

}

外观类

public class Facade{
    private SubSystemA obj1 = new SubSystemA();
    private SubSystemB obj2 = new SubSystemB();
    private SubSystemC obj3 = new SubSystemC();

    public void method(){
        obj1.methodA();
        obj2.methodB();
        obj3.methodC();
    }
}

客户端

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

抽象外观类

在标准的外观模式结构图中,如果需要增加,删除或更换与外观类交互的子系统类,必须修改外观类或客户端的源代码,这将违背开闭原则,因此可以通过引入抽象外观类对系统进行改进,这在一定程度上可以解决该问题.

可以通过抽象外观类对系统进行改进,在引入抽象外观类之后,客户端针对抽象外观类进行编程,对于新的业务需求,不需要修改原有外观类,而只需对应增加一个新的具体外观类,由新的具体外观类来关联新的子系统对象,同时通过修改配置文件达到不修改任何源代码并更换外观类的目的.

外观模式优/缺点与适用环境

所有涉及与多个业务对象交互的场景都可以考虑使用外观模式进行重构,例如Java EE中的Session外观模式.

外观模式的优点:

对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使子系统使用起来更加容易.

外观模式的缺点:

不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性.
如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开闭原则.

外观模式适用环境:

要为访问一系列复杂的子系统提供一个简单入口.
客户端程序与多个子系统之间存在很大的依赖性.
在层次化结构中可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度.