从零开始学设计模式(九):外观模式(Facade Pattern)

这是我参与11月更文挑战的第16天,活动详情查看:2021最后一次更文挑战

作者的其他平台:

| CSDN:blog.csdn.net/qq\_4115394…

| 掘金:juejin.cn/user/651387…

| 知乎:www.zhihu.com/people/1024…

| GitHub:github.com/JiangXia-10…

| 公众号:1024笔记

本文大概2505字,读完共需7分钟

定义:

外观(Facade)模式又叫作门面模式,是一种为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口,外部与其中子系统的通信必须通过一个统一的外观对象进行,外部应用程序不用关心内部子系统的具体细节,这样会大大降低应用程序的复杂度,使得这一子系统更加容易使用,提高了程序的可维护性。外观模式是一种对象结构型模式。

在上海有个软件叫随申办的软件,以前我们如果要办理社保、办理公积金、办理过户、办理水电等等,都需要去负责这些事情的部门或者下载对应的软件,但是随申办这个软件整合这些部门的功能,想要办理这些事情,只需要登录随申办就可以了。随申办软件就相当于这个对外统一的接口,它负责用户和里面每个子系统的通信。

组成部分:

通过上面对于外观模式的介绍,可以发现外观模式应该有以下两个个部分组成:

1,外观(Facade)角色 :为多个子系统对外提供一个共同的接口。客户端可以调用这个角色的方法。外观角色整合了相关子系统的功能和责任,将所有从客户端发来的请求分发到相应的子系统去。

2,子系统(Sub System)角色 :实现系统的部分功能,客户端通过外观角色访问它可以同时有一个或者多个子系统。每个子系统都不是一个单独的类,而是一个类的集合。每个子系统都可以被客户端直接调用,或者被外观角色调用。对于子系统而言,它并不知道外观角色的存在,对于子系统而言,外观角色可以理解为另外一个客户端。

栗子:

声明一个接口:

public interface Person {
    void say();
}
复制代码

创建接口实现类,即子系统:

public class Chirldren implements Person {
    @Override
    public void say() {
        System.out.println("小孩说话咿呀咿呀");
    }
}
复制代码
public class YoungMan implements Person {
    @Override
    public void say() {
        System.out.println("年轻人说话哈哈哈哈");
    }
}
复制代码
public class OldMan implements Person {
    @Override
    public void say() {
        System.out.println("老年人说话嗯嗯嗯嗯");
    }
}

复制代码

创建整合操作的对外的外观类,即外观角色:

public class PersonFacade {

    private Person chirldren;

    private Person youngman;

    private Person oldman;

    public PersonFacade() {
        this.chirldren = new Chirldren();
        this.youngman = new YoungMan();
        this.oldman = new OldMan();
    }

    public void sayFacade(){
        chirldren.say();
        youngman.say();
        oldman.say();
    }
}

复制代码

测试类,即客户端、用户:

public class FacedePatternTest {
    public static void main(String[] args) {
        PersonFacade personFacade = new PersonFacade();
        personFacade.sayFacade();
    }
}
复制代码

运行结果如下:

外观模式的优点:

1、外观模式实现了子系统与客户端之间的松耦合关系。这使得子系统的组件变化不会影响到调用它的客户类,只需要调整外观类即可。

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

3、通过引入外观模式,客户代码将变得很简单,与之关联的对象也很少。

4、只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类

外观模式的缺点

1、不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。

2、在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了"开闭原则"。

适用场景:

1、当要为一个复杂子系统提供一个简单接口时可以使用外观模式。该接口可以满足大多数用户的需求,而且用户也可以越过外观类直接访问子系统。

2、在设计初期阶段,应该有意识的将不同层分离,层与层之间建立外观模式,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。;开发阶段,子系统越来越复杂,增加外观模式提供一个简单的调用接口。

3、当需要维护一个老系统时,可以为其开发一个外观类,以便新系统与其交互。

总结:

1、外观模式实现了子系统与客户端之间的松耦合关系。

2、外观模式为复杂子系统提供了一个简单接口,并不为子系统添加新的功能和行为。

3、外观模式注重的是简化接口,它更多的时候是从架构的层次去看整个系统,而并非单个类的层次。

4、外观模式没有封装子系统的类,只是提供了简单的接口。如果应用需要,它并不限制客户使用子系统类。因此可以灵活的在系统易用性与通用性之间选择。

5、外观模式实现了迪米特法则,但是违背了开闭原则。

相关推荐:

从零开始学设计模式(一):什么是设计模式

从零开始学设计模式(二):单例模式

从零开始学设计模式(三):原型模式(Prototype Pattern)

从零开始学设计模式(四):工厂模式(Factory Pattern)

从零开始学设计模式(五):建造者模式(Builder Pattern)

从零开始学设计模式(六):适配器模式(Adapter Pattern)

从零开始学设计模式(六):代理模式(Proxy Pattern)

从零开始学设计模式(八):装饰器模式(Decorator Pattern)

猜你喜欢

转载自juejin.im/post/7031160279706632228
今日推荐