设计模式结构型——外观模式

目录

什么是外观模式

外观模式的实现

外观模式的特点

---

什么是外观模式

        外观模式（Facade Pattern）：又叫作门面模式，归属于结构型模式。外观模式定义了提供了定义了一个统一的高层接口，即为子系统中的一组接口提供一个一致的访问入口，使子系统更容易被外部程序统一调用。外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

        外观模式是为了解决类与类之家的依赖关系的，像spring一样，可以将类和类之间的关系配置到配置文件中，而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度。

外观模式的实现

外观模式包含如下角色：

外观角色（Facade）：为多个子系统对外提供一个共同的接口，知道哪些子系统负责处理请求，将客户端的请求转发给适当的子系统对象。
子系统角色（Sub System）：实现子系统的功能，处理外观角色指派的任务。客户可以通过外观角色访问它。子系统在整个系统中可以是一个或多个模块，每个模块都有若干类组成，这些类可能相互之间有着比较复杂的关系。
客户角色（Client）：调用外观角色访问各个子系统的功能。

        举个例子: 比如去图书馆借书, 但图书馆很大不知道所要的东西在哪里. 于是就去问图书馆管理员, 图书馆管理员会马上找到你所要的图书. 这里面我们不用了解图书馆图书的摆放, 直接找图书馆管理员即可. 图书馆管理员这里就是门面, 图书的摆放就是内部构造.

        这里你代表客户角色，图书代表子系统角色，图书馆管理员代表外观角色。

外观模式类图

外观模式代码实现

        举个例子，一美女下班回家，第一件开门，然后是开灯，然后打开空调，打开热水器，躺在沙发上准备看电视。在智能家居的场景，所有电器都绑定啦小爱同学上，其他遥控我们无需关注，只需要关注小爱同学就好啦。这个时候我们就可以使用外观模式。
        其中：美女属于客户角色，小爱同学属于外观角色，智能门锁，电灯，空调，热水器，电视属于子系统角色。

子系统角色

package com.common.demo.pattern.facade;

/**
 * @author Evan Walker https://www.ayshuju.com
 * @version 1.0
 * @desc 门锁 子系统角色
 * @date 2023/07/20 11:05:13
 */
public class Lock {

    public void open(){
        System.out.println("打开门锁>>>>>>门锁已打开！");
    }
}
package com.common.demo.pattern.facade;

/**
 * @author Evan Walker https://www.ayshuju.com
 * @version 1.0
 * @desc 电灯 子系统角色
 * @date 2023/07/20 11:03:03
 */
public class Light {

    public void open(){
        System.out.println("打开电灯>>>>>>电灯已打开！");
    }
}
package com.common.demo.pattern.facade;

/**
 * @author Evan Walker  https://www.ayshuju.com
 * @version 1.0
 * @desc 空调 子系统角色
 * @date 2023/07/20 11:07:38
 */
public class AirConditioner {

    public void open(){
        System.out.println("打开空调>>>>>>空调已打开!");
    }
}
package com.common.demo.pattern.facade;

/**
 * @author Evan Walker  https://www.ayshuju.com
 * @version 1.0
 * @desc 热水器 子系统角色
 * @date 2023/07/20 11:03:53
 */
public class Heater {

    public void open(){
        System.out.println("打开热水器>>>>>>热水器已打开！");
    }
}
package com.common.demo.pattern.facade;

/**
 * @author Evan Walker https://www.ayshuju.com
 * @version 1.0
 * @desc 电视 子系统角色
 * @date 2023/07/20 11:06:04
 */
public class Tv {

    public void open(){
        System.out.println("打开电视>>>>>>电视已打开！");
    }
}

外观角色

package com.common.demo.pattern.facade;

/**
 * @author Evan Walker  https://www.ayshuju.com
 * @version 1.0
 * @desc 外观角色
 * @date 2023/07/20 10:59:00
 */
public class Facade {

    private AirConditioner airConditioner;
    private Tv tv;
    private Lock lock;
    private Light light;
    private Heater heater;

    public Facade(){
        this.airConditioner = new AirConditioner();
        this.tv = new Tv();
        this.light = new Light();
        this.lock = new Lock();
        this.heater = new Heater();
    }

    public void goHome(){
        lock.open();
        light.open();
        airConditioner.open();
        heater.open();
        tv.open();
    }

}

客户角色

package com.common.demo.pattern.facade;

/**
 * @author Evan Walker  https://www.ayshuju.com
 * @version 1.0
 * @desc 客户角色
 * @date 2023/07/20 10:59:15
 */
public class Client {

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

运行测试截图

外观模式的特点

优点

1. 减少相互依赖：实现了子系统与客户之间的松耦合关系，子系统的组件变化不会影响到调用它的客户类，只需调整外观类即可。
2. 提高灵活性：对客户屏蔽子系统组件，减少了客户处理的对象数目，客户代码使用子系统使用起来更加容易。但并不妨碍客户直接访问子系统。
3. 提高安全性：更好地划分访问层次。
4. 迪米特法则：遵循迪米特法则，即最少知道原则。

缺点

1. 当增加子系统和扩展系统行为时，可能容易带来未知风险。
2. 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
3. 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
4. 某些情况下可能违背单一职责原则。
    

注意事项

1. 在层次化结构中，可使用外观模式定义系统中每一层的入口。
2. 一个系统有多个外观类，在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。
3. 不要试图通过外观类为子系统增加新行为，外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。
4. 外观模式创造出一个外观对象，将客户端所涉及的属于一个子系统的协作伙伴的数量减到最少，使得客户端与子系统内部的对象的相互作用被外观对象所取代。外观类充当了客户类与子系统类之间的“第三者”，降低了客户类与子系统类之间的耦合度，外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。
5. 外观模式最大的缺点在于违背了“开闭原则”，当增加新的子系统或者移除子系统时需要修改外观类，可以通过引入抽象外观类在一定程度上解决该问题，客户端针对抽象外观类进行编程。对于新的业务需求，不修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改源代码并更换外观类的目的。

应用场景

1. 减少对子系统的依赖性
2. 子系统相对独立且越来越复杂，增加门面模式提供接口
3. 构建多层系统结构，利用门面对象作为每层的入口，简化层间调用

总结

1. 外观模式对客户端与子系统的耦合关系，让子系统内部的模块更易维护和扩展。对外屏蔽了子系统的细节，因此外观模式降低了客户端对子系统使用的复杂性。当系统需要进行分层设计时，可以考虑外观模式帮我们更好的划分访问的层次。

更多消息资讯，请访问昂焱数据（https://www.ayshuju.com）