研磨设计模式day03外观模式

目录

场景

代码描述

不用模式的解决方案 

存在的问题

解决方案

示例代码

​编辑模式讲解

使用外观与不使用外观有何变化

有外观也可以不使用

外观模式的优缺点

外观模式思考

如何选用外观模式

高级用法

模块解释

---

场景

自己组装电脑时，需要对各个模块熟悉，如果我们不熟悉那么我们可以找一个专门的装机公司，给他们提出要求，他们帮我装机。

这个专业的装机公司就相当于外观模式。有了它，我们就不用自己去和众多卖配件的公司打交道。

代码描述

 

不用模式的解决方案 

 描述配置的数据Model类,并生成对应的getter setter

 配置管理的实现代码

各个层生成代码的模块：获取配置文件的内容，然后按照配置生成对应的代码

表现层

逻辑层

DAO层

 客户端使用

存在的问题

客户端在使用时需要跟各个模块进行交互，对于客户端而言，使得客户端不能简单地使用生成代码的功能，而且一旦某个模块发生变化，还可能引起客户端随之变化。

解决方案

外观模式

外观模式的结构说明

 

示例代码

新建一个Facade对象

客户端实现

模式讲解

外观模式只是当作系统对外的接口出现，虽然也可以定义子系统没有的功能，但不建议这么做。

外观应该是包装已有的功能，主要负责组合已有功能，而不是添加新的实现

使用外观与不使用外观有何变化

有外观也可以不使用

外观模式的优缺点

外观模式思考

本质：封装交互，简化使用

对设计原则的体现：最少知识原则，如果不使用外观模式，客户端需要跟子系统的多个模块进行交互，也就是说客户端会有很多的朋友；使用外观模式之后，客户端只有外观类Facade这一个朋友。

如何选用外观模式

高级用法

外观模式与简单工厂模式

1.客户端入口

2. FacadeFactory.class

3.FacadeImpl.class

4.Factory.class

5.FacadeApi接口

6.A、B、C各自模块及实现类

模块解释

客户端想调用abc模块中对外暴露的方法，我们提供一个FacadeFactory工厂，工厂提供创建FacadeApi的方法，FacadeApi有一次性获取所有的方法，但是这个方法不是FacadeImpl直接实现的，是由Factory工厂提供的，FacadeImpl只是知道它从工厂获取它需要的功能，Factory工厂包裹着ABC三个模块的实现。根据Factory这个工厂可以自由的向外提供服务。