肝一肝设计模式【八】-- 外观模式

系列文章目录

肝一肝设计模式【一】-- 单例模式 传送门
肝一肝设计模式【二】-- 工厂模式 传送门
肝一肝设计模式【三】-- 原型模式 传送门
肝一肝设计模式【四】-- 建造者模式 传送门
肝一肝设计模式【五】-- 适配器模式 传送门
肝一肝设计模式【六】-- 装饰器模式 传送门
肝一肝设计模式【七】-- 代理模式 传送门

---

---

前言

本节我们继续分析设计模式中的结构型模式，前文中我们已经分析了适配器模式、装饰器模式、代理模式，本节我们来学习一下——外观模式。

---

一、外观模式是什么

外观模式（Facade Pattern），它为复杂子系统提供了一个简单的接口，使得客户端可以更容易地使用该子系统，同时避免了直接访问子系统可能带来的复杂性。

外观模式的核心思想是为子系统提供一个高层次的接口，以便客户端可以通过这个接口访问子系统的功能，而无需了解子系统的内部实现细节。外观模式封装了子系统的复杂性，提供了一个简单的界面，使得客户端可以更加方便地使用子系统的功能。

二、外观模式中的角色

通常情况下，外观模式的实现需要创建一个外观类，该类将客户端的请求委派给子系统中的相应对象进行处理。外观类对客户端隐藏了子系统的复杂性，同时还可以为子系统提供额外的功能，以满足客户端的需求。

外观模式主要由三个角色：

• 外观（Facade）：外观是外观模式的核心，它封装了子系统的复杂性，并为客户端提供一个简单的接口。外观类通常包含一个或多个操作方法，这些方法将客户端的请求委派给子系统中的相应对象进行处理。外观类还可以为客户端提供一些额外的功能，以便满足客户端的需求。
• 子系统（Subsystem）：子系统是外观模式中的核心组成部分，它是指实现系统功能的一组类。子系统包含一些相互关联的类，这些类共同实现了系统的一些功能。在外观模式中，客户端通常不会直接访问子系统中的类，而是通过外观类来访问子系统。
• 客户端（Client）：客户端是使用外观模式的应用程序的组成部分。客户端通过外观类来访问子系统中的功能，从而实现系统的需求。客户端并不了解子系统的内部实现细节，它只需要调用外观类中的方法即可完成所需功能。

三、举个栗子

又到了举例子环节，比如单独一个人去医院看病，往往会因为挂号、化验、取报告、收费、取药等这些流程搞得焦头烂额，当你刚刚花了半个小时排完队交完费，转头看到取药窗口的长队时，当下的我崩溃如下图。。
实际生活中像我经历的这种情况不在少数，而这就催生出一种服务叫陪诊服务，用户只需要专注看病这件事就行了，其他都交给陪诊员，这种形式的服务就和程序中外观模式的概念就很类似了

上代码：

我们把取报告、交费、取药这几个步骤当做子系统

public class StepA {public void getReport() {System.out.println("帮我取化验报告");}
}

public class StepB {public void pay() {System.out.println("帮我去交费");}
}

public class StepC {public void getMedicine() {System.out.println("帮我把药取回来");}
}

陪诊员相当于外观角色

public class AccompanyFacade {private StepA stepA;private StepB stepB;private StepC stepC;public AccompanyFacade() {stepA = new StepA();stepB = new StepB();stepC = new StepC();}public void work() {stepA.getReport();stepB.pay();stepC.getMedicine();}
}

客户端调用

public class FacadeClient {public static void main(String[] args) {AccompanyFacade facade= new AccompanyFacade();facade.work();}
}

四、在开源框架中的使用

SLF4J（Simple Logging Facade for Java）是一个常用的日志框架，它使用了外观模式来封装不同的日志实现库，提供了统一的接口供开发人员使用。SLF4J允许开发人员在代码中使用一致的日志API，而无需关注底层的日志实现细节。

SLF4J的核心组件是Logger接口，它定义了常见的日志方法，如debug()、info()、error()等。开发人员可以通过获取Logger实例并调用这些方法来记录日志。

SLF4J的外观模式实现的关键在于它提供了适配器（Adapter）和桥接（Bridge）两个重要的概念：

• 适配器（Adapter）：SLF4J提供了适配器模块，例如slf4j-jdk14、slf4j-log4j12等，用于适配不同的日志实现库，将它们转换为SLF4J接口的调用。这样，开发人员可以使用SLF4J的接口，而实际的日志实现则由相应的适配器来负责。

• 桥接（Bridge）：SLF4J还提供了桥接模块，例如jul-to-slf4j、log4j-to-slf4j等，用于将其他日志库的日志输出重定向到SLF4J接口。这样，即使在使用其他日志库的应用中，开发人员仍然可以通过SLF4J接口来统一管理日志。

通过适配器和桥接的机制，SLF4J实现了外观模式，封装了不同的日志实现库，提供了统一的日志接口供开发人员使用。这样，开发人员可以轻松切换和管理日志库，而无需修改大量的代码。

SLF4J本身只提供了日志接口和相关的适配器和桥接模块，实际的日志输出仍需要依赖具体的日志实现库，例如Logback、Log4j等。开发人员需要在项目中同时引入SLF4J和所选的日志实现库。

以下是SLF4J的部分源代码，展示了它的外观模式实现：

Logger接口：

public interface Logger {void debug(String message);void info(String message);void error(String message);// ...
}

LoggerFactory类：

public final class LoggerFactory {private LoggerFactory() {}public static Logger getLogger(Class<?> clazz) {// 获取适配器实例ILoggerFactory loggerFactory = getILoggerFactory();return loggerFactory.getLogger(clazz.getName());}private static ILoggerFactory getILoggerFactory() {// 返回适配器实例return StaticLoggerBinder.getSingleton().getLoggerFactory();}
}

StaticLoggerBinder类：

public class StaticLoggerBinder {private static final StaticLoggerBinder SINGLETON = new StaticLoggerBinder();private final ILoggerFactory loggerFactory = new MyLoggerFactory();public static final StaticLoggerBinder getSingleton() {return SINGLETON;}public ILoggerFactory getLoggerFactory() {return loggerFactory;}
}

适配器实现：

public class Log4jLoggerFactory implements ILoggerFactory {public Logger getLogger(String name) {return new Log4jLogger(org.apache.log4j.Logger.getLogger(name));}
}

在上述代码中，Logger接口定义了常见的日志方法，LoggerFactory类是获取Logger实例的工厂类。LoggerFactory通过调用getILoggerFactory()方法获取适配器实例，然后返回相应的Logger实例。

StaticLoggerBinder类是一个单例类，提供了getLoggerFactory()方法来获取适配器实例。在示例中，适配器实现为Log4jLoggerFactory，它实现了ILoggerFactory接口，并通过Log4j库来实现日志功能。

这样，当开发人员通过LoggerFactory.getLogger()获取Logger实例时，SLF4J会根据适配器的实现来选择相应的日志实现库，然后返回封装好的Logger实例。开发人员可以直接使用Logger接口的方法来记录日志，而无需关心具体的日志实现细节。

---

写在最后

外观模式的优点：

• 简化接口：外观模式通过提供一个统一的接口，将底层子系统的复杂性封装起来。这样，使用者只需要与外观对象交互，无需了解底层子系统的具体实现细节，简化了接口和调用过程。

• 提供易用性：外观模式可以为使用者提供一个简单而易用的接口，降低了学习和使用系统的难度。使用者无需深入了解系统的内部结构和复杂性，可以更快地上手和开发。

• 解耦和降低依赖：外观模式将系统的子系统和使用者之间进行解耦，通过外观对象进行交互。这样，子系统的变化不会影响到使用者，使用者只需要关注外观对象的接口，减少了依赖关系。

• 提供灵活性和可维护性：通过外观模式，可以隔离系统的变化和演化。当底层子系统发生变化时，只需要调整外观对象的实现，而不需要修改使用者的代码。这提供了灵活性和可维护性，降低了系统的耦合度。

外观模式的缺点：

• 违背开闭原则：外观模式的一个潜在缺点是当系统的需求变化时，可能需要修改外观对象的接口或实现。这可能导致外观对象的修改，违背了开闭原则。但通常情况下，外观模式的修改范围相对较小，不会对系统的其他部分产生太大影响。

• 可能引入性能问题：在某些情况下，外观模式可能会引入性能问题。由于外观对象需要处理复杂的子系统调用，可能会导致一定的性能开销。但在大多数情况下，这种开销是可以接受的，并且可以通过优化和缓存等技术进行改进。