莆田市荔城区建设局网站,flashfxp 网站,模板网站的建设方式与方法,网站建设初期的工作计划系列文章目录
肝一肝设计模式【一】-- 单例模式 传送门 肝一肝设计模式【二】-- 工厂模式 传送门 肝一肝设计模式【三】-- 原型模式 传送门 肝一肝设计模式【四】-- 建造者模式 传送门 肝一肝设计模式【五】-- 适配器模式 传送门 肝一肝设计模式【六】-- 装饰器模式 传送门 肝…系列文章目录
肝一肝设计模式【一】-- 单例模式 传送门 肝一肝设计模式【二】-- 工厂模式 传送门 肝一肝设计模式【三】-- 原型模式 传送门 肝一肝设计模式【四】-- 建造者模式 传送门 肝一肝设计模式【五】-- 适配器模式 传送门 肝一肝设计模式【六】-- 装饰器模式 传送门 肝一肝设计模式【七】-- 代理模式 传送门 文章目录 系列文章目录前言一、外观模式是什么二、外观模式中的角色三、举个栗子四、在开源框架中的使用写在最后 前言
本节我们继续分析设计模式中的结构型模式前文中我们已经分析了适配器模式、装饰器模式、代理模式本节我们来学习一下——外观模式。 一、外观模式是什么
外观模式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();}
}四、在开源框架中的使用
SLF4JSimple Logging Facade for Java是一个常用的日志框架它使用了外观模式来封装不同的日志实现库提供了统一的接口供开发人员使用。SLF4J允许开发人员在代码中使用一致的日志API而无需关注底层的日志实现细节。
SLF4J的核心组件是Logger接口它定义了常见的日志方法如debug()、info()、error()等。开发人员可以通过获取Logger实例并调用这些方法来记录日志。
SLF4J的外观模式实现的关键在于它提供了适配器Adapter和桥接Bridge两个重要的概念 适配器AdapterSLF4J提供了适配器模块例如slf4j-jdk14、slf4j-log4j12等用于适配不同的日志实现库将它们转换为SLF4J接口的调用。这样开发人员可以使用SLF4J的接口而实际的日志实现则由相应的适配器来负责。 桥接BridgeSLF4J还提供了桥接模块例如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接口的方法来记录日志而无需关心具体的日志实现细节。 写在最后
外观模式的优点 简化接口外观模式通过提供一个统一的接口将底层子系统的复杂性封装起来。这样使用者只需要与外观对象交互无需了解底层子系统的具体实现细节简化了接口和调用过程。 提供易用性外观模式可以为使用者提供一个简单而易用的接口降低了学习和使用系统的难度。使用者无需深入了解系统的内部结构和复杂性可以更快地上手和开发。 解耦和降低依赖外观模式将系统的子系统和使用者之间进行解耦通过外观对象进行交互。这样子系统的变化不会影响到使用者使用者只需要关注外观对象的接口减少了依赖关系。 提供灵活性和可维护性通过外观模式可以隔离系统的变化和演化。当底层子系统发生变化时只需要调整外观对象的实现而不需要修改使用者的代码。这提供了灵活性和可维护性降低了系统的耦合度。
外观模式的缺点 违背开闭原则外观模式的一个潜在缺点是当系统的需求变化时可能需要修改外观对象的接口或实现。这可能导致外观对象的修改违背了开闭原则。但通常情况下外观模式的修改范围相对较小不会对系统的其他部分产生太大影响。 可能引入性能问题在某些情况下外观模式可能会引入性能问题。由于外观对象需要处理复杂的子系统调用可能会导致一定的性能开销。但在大多数情况下这种开销是可以接受的并且可以通过优化和缓存等技术进行改进。
