小谈设计模式(13)—外观模式

小谈设计模式(13)---外观模式

专栏介绍

专栏地址

link

专栏介绍

主要对目前市面上常见的23种设计模式进行逐一分析和总结,希望有兴趣的小伙伴们可以看一下,会持续更新的。希望各位可以监督我,我们一起学习进步,加油,各位。

外观模式

外观模式(Facade Pattern)是一种结构型设计模式,它提供了一个统一的接口,用于访问子系统中的一组接口。外观模式定义了一个高层接口,使得子系统更容易使用。

主要目的

简化复杂系统的接口。它通过提供一个统一的接口,隐藏了子系统的复杂性,使得客户端可以更方便地使用系统。外观模式通过将客户端与子系统解耦,提供了一个简化的接口,从而降低了系统的复杂性。

角色分析

外观(Facade)角色

外观角色是外观模式的核心。它知道哪些子系统类负责处理请求,并将客户端的请求委派给适当的子系统对象。外观角色通常是单例模式,可以提供一个简单的接口,隐藏了子系统的复杂性。

子系统(Subsystem)角色

子系统角色是外观模式中的各个子系统类。它们是实际处理请求的类,完成具体的功能。外观角色将客户端的请求委派给适当的子系统对象,由子系统对象完成具体的操作。

客户端(Client)角色

客户端角色是使用外观模式的类。它通过调用外观角色的接口来完成操作,而不需要直接与子系统类交互。客户端角色只需要知道外观角色提供的简单接口,无需了解子系统的复杂性。

工作原理

客户端通过调用外观角色的接口来进行操作,外观角色将请求委派给适当的子系统对象,子系统对象完成具体的操作并返回结果给客户端。客户端无需了解子系统的复杂性,只需要通过外观角色来访问子系统。这样可以降低系统的复杂性,提高系统的可维护性和可扩展性。

核心思想总结

简化接口

外观角色提供了一个简化的接口,将子系统的一组接口封装起来,使得客户端可以更方便地使用系统。客户端只需要调用外观角色的接口,无需了解子系统的复杂性。

解耦客户端和子系统

外观模式将客户端与子系统解耦,客户端只需要与外观角色交互,而不需要直接与子系统类交互。这样可以降低客户端的复杂性,同时也提高了系统的可维护性和可扩展性。

隐藏实现细节

外观模式将子系统的实现细节隐藏起来,只暴露给客户端一个简单的接口。这样可以保护子系统的实现细节,防止客户端直接访问和修改子系统的内部实现。

Java程序实现

java 复制代码
// 子系统类A
class SubsystemA {
    public void operationA() {
        System.out.println("SubsystemA operation");
    }
}

// 子系统类B
class SubsystemB {
    public void operationB() {
        System.out.println("SubsystemB operation");
    }
}

// 外观类
class Facade {
    private SubsystemA subsystemA;
    private SubsystemB subsystemB;

    public Facade() {
        subsystemA = new SubsystemA();
        subsystemB = new SubsystemB();
    }

    public void operation() {
        subsystemA.operationA();
        subsystemB.operationB();
    }
}

// 客户端类
public class Client {
    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.operation();
    }
}

程序分析

在上面的示例中,我们定义了两个子系统类 SubsystemA 和 SubsystemB,它们分别实现了不同的操作。然后我们定义了一个外观类 Facade,它将子系统类封装起来,并提供了一个简化的接口 operation。客户端类 Client 使用外观类来完成操作,而不需要直接与子系统类交互。

优缺点分析

优点

简化客户端的操作

外观模式提供了一个简化的接口,隐藏了子系统的复杂性,使客户端更容易使用。

解耦客户端和子系统

外观模式将客户端与子系统解耦,客户端只需要与外观类进行交互,不需要直接与子系统类交互,降低了客户端的复杂性。

提高系统的可用性和可维护性

外观模式将子系统的实现细节封装起来,保护了子系统的实现细节,使系统更加稳定和可维护。

缺点

可能导致系统变得更加复杂

当系统变得复杂时,外观类可能会变得庞大,难以维护。

限制了灵活性

外观模式隐藏了子系统的复杂性,但也限制了客户端对子系统的灵活访问。

总结

外观模式在简化客户端操作、解耦客户端和子系统、提高系统可用性和可维护性方面具有很大的优势,适用于需要隐藏复杂子系统的情况。但需要注意在设计时避免外观类变得庞大和过于复杂,以及权衡灵活性和封装性。

相关推荐
触底反弹2 小时前
🤯 面试被问 AI Workflow 和 Agent 有啥区别?3 张图 + 2 段代码讲清楚!
人工智能·设计模式·面试
杨充1 天前
10.可测试性实战设计
设计模式·开源·代码规范
杨充1 天前
9.重构十二式的实战
设计模式·开源·代码规范
杨充1 天前
6.设计原则的全景图
设计模式·开源·全栈
杨充1 天前
2.面向对象的特性
设计模式
杨充1 天前
7.SOLID原则案例汇
设计模式·开源·全栈
杨充1 天前
8.反模式与坏味道
设计模式·开源·代码规范
杨充1 天前
3.接口vs抽象类比较
设计模式
咖啡八杯1 天前
文法、BNF与AST
java·设计模式·解释器模式·ast·文法