前言
本文的主要内容:
- 介绍外观模式
- 示例
- 自己泡茶
- 到茶馆喝茶
- 外观模式总结
- 外观模式的典型应用
- spring JDBC 中的外观模式
- Mybatis中的外观模式
- Tomcat 中的外观模式
- SLF4J 中的外观模式
外观模式
外观模式是一种使用频率非常高的结构型设计模式,它通过引入一个外观角色来简化客户端与子系统之间的交互,为复杂的子系统调用提供一个统一的入口,降低子系统与客户端的耦合度,且客户端调用非常方便。
外观模式又称为门面模式,它是一种对象结构型模式。外观模式是迪米特法则的一种具体实现,通过引入一个新的外观角色可以降低原有系统的复杂度,同时降低客户类与子系统的耦合度。
外观模式包含如下两个角色:
Facade(外观角色):在客户端可以调用它的方法,在外观角色中可以知道相关的(一个或者多个)子系统的功能和责任;在正常情况下,它将所有从客户端发来的请求委派到相应的子系统去,传递给相应的子系统对象处理。
SubSystem(子系统角色):在软件系统中可以有一个或者多个子系统角色,每一个子系统可以不是一个单独的类,而是一个类的集合,它实现子系统的功能;每一个子系统都可以被客户端直接调用,或者被外观角色调用,它处理由外观类传过来的请求;子系统并不知道外观的存在,对于子系统而言,外观角色仅仅是另外一个客户端而已。
外观模式的目的不是给予子系统添加新的功能接口,而是为了让外部减少与子系统内多个模块的交互,松散耦合,从而让外部能够更简单地使用子系统。
外观模式的本质是:封装交互,简化调用。
示例
泡茶需要水 Water
1 | 复制代码public class Water { |
泡茶需要茶叶 TeaLeaf
1 | 复制代码public class TeaLeaf { |
烧水需要用水壶烧,将水加热
1 | 复制代码public class KettleService { |
泡茶,将烧好的水与茶叶进行冲泡,最终得到一杯茶水
1 | 复制代码public class TeasetService { |
人喝茶水
1 | 复制代码public class Man { |
自己泡茶喝
张三、李四各自泡茶喝,各自都需要准备茶具、茶叶、水,各自还要完成烧水、泡茶等操作
1 | 复制代码public class Main { |
输出为
1 | 复制代码张三 使用水壶烧水,最终水温为 80 |
自己泡茶喝模式图
到茶馆喝茶
茶馆,茶馆有不同的套餐
1 | 复制代码public class TeaHouseFacade { |
张三和李四点茶,只需要告诉茶馆套餐编号即可,水、茶叶由茶馆准备,烧水泡茶的操作由茶馆统一完成
1 | 复制代码public class Test { |
输出为
1 | 复制代码老舍茶馆 使用水壶烧水,最终水温为 80 |
到茶馆喝茶模式图
外观模式总结
外观模式的主要优点如下:
- 它对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易。通过引入外观模式,客户端代码将变得很简单,与之关联的对象也很少。
- 它实现了子系统与客户端之间的松耦合关系,这使得子系统的变化不会影响到调用它的客户端,只需要调整外观类即可。
- 一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。
外观模式的主要缺点如下:
- 不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
- 如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开闭原则。
适用场景:
- 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。
- 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦,从而提高子系统的独立性和可移植性。
- 在层次化结构中,可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。
源码分析外观模式的典型应用
spring jdbc中的外观模式
查看 org.springframework.jdbc.support.JdbcUtils
1 | 复制代码public abstract class JdbcUtils { |
该工具类主要是对原生的 jdbc 进行了封装
Mybatis中的外观模式
查看 org.apache.ibatis.session.Configuration
类中以 new
开头的方法
1 | 复制代码public class Configuration { |
该类主要对一些创建对象的操作进行封装
Tomcat 中的外观模式
Tomcat 源码中大量使用了很多外观模式
org.apache.catalina.connector.Request
和 org.apache.catalina.connector.RequestFacade
这两个类都实现了 HttpServletRequest
接口
在 Request
中调用 getRequest()
实际获取的是 RequestFacade
的对象
1 | 复制代码protected RequestFacade facade = null; |
在 RequestFacade
中再对认为是子系统的操作进行封装
1 | 复制代码public class RequestFacade implements HttpServletRequest { |
SLF4J 中的外观模式
SLF4J
是简单的日志外观模式框架,抽象了各种日志框架例如 Logback
、Log4j
、Commons-logging
和 JDK
自带的 logging
实现接口。它使得用户可以在部署时使用自己想要的日志框架。
SLF4J
没有替代任何日志框架,它仅仅是标准日志框架的外观模式。如果在类路径下除了 SLF4J
再没有任何日志框架,那么默认状态是在控制台输出日志。
日志处理框架 Logback 是 Log4j 的改进版本,原生支持SLF4J(因为是同一作者开发的),因此 Logback+SLF4J 的组合是日志框架的最佳选择,比 SLF4J+其它日志框架 的组合要快一些。而且Logback的配置可以是XML或Groovy代码。
SLF4J 的 helloworld 如下:
1 | 复制代码import org.slf4j.Logger; |
下图为 SLF4J 与日志处理框架的绑定调用关系
应用层调用 slf4j-api.jar
,slf4j-api.jar
再根据所绑定的日志处理框架调用不同的 jar 包进行处理
参考:
刘伟:设计模式Java版
慕课网java设计模式精讲 Debug 方式+内存分析
推荐阅读
点击[阅读原文]可访问我的个人博客:laijianfeng.org
本文转载自: 掘金