门面设计模式12
一、定义
门面模式又称为外观模式,该模式把一个模块中的多个类的公共接口封装到一个“统一接口”中,而门面类拥有一个或多个这样的“统一接口”。再简单一点理解就是封装“流程”,简化调用。
为多个复杂的子系统提供一个统一的访问入口
最简单的例子就是一个电脑,封装了CPU、内存、显卡等。电脑视为门面,我们与电脑打交道。
另外就是Activity工作流的很多Service,我们可以将其全部封装到一个类中,然后封装指定的流程,客户端只需要提供参数,例如任务的ID。
推荐我认为非常非常好的博客:
外观模式(Facade模式)详解 (核心)
设计模式(七)门面模式(Facade Pattern 外观模式)
二、外观设计模式的角色
-----> 表示是临时性的关联。在代码中,某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类
门面角色。门面类持有子系统角色的引用,因此熟悉子系统中的所有公共接口,并能够调用它们。
子系统角色:一个子系统类可以视为一个独立的模块,这个模块中实现了大量的业务逻辑功能。一个门面类中可以有多个子系统类。
客户端角色:什么是客户端,我的理解就是最上层调用环境。它专门调用门面角色。
三、优缺点
核心心法:门面设计模式是组合现有的功能
客户端不与各个子系统或者功能模块直接打交道,降低客户端复杂度。
缺点也很明显,当子系统功能修改的时候,门面里面也要修改相关的代码。(以前在调用环境要动的代码,现在挪到门面里面去动了)
优点:
1.降低调用环境与子系统之间的耦合,调用环境只与门面类耦合,而不与多个子系统类耦合。当需求发生变更的时候,编写新的门面类,替换掉原来的门面类。
2.简单好用。因为门面类中封装子系统类,可以将它们的业务逻辑流程封装到一个统一方法中,调用环境只需要直接调用门面类的那个统一方法,因此简单好用
3.在层次化结构中,可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。
缺点:
因为需求变更导致的逻辑代码变动,导致以前的门面类不能满足现在的需求,因此需要修改原来的代码,不符合开放闭合原则。解决方法是把门面类也抽象,编写新的门面类实现抽象门面类,使用修改配置文件的方法替换旧的门面类。但这样,无异于要编写读取配置文件的流操作代码,可以预见到,很可能有一个专门生成门面实现类的单例工厂,这样无异于增加了代码开发量。
四、心法
封装交互,简化调用,降低耦合。
层与层之间使用门面对接,封装了不同层次的交互。
不要试图去修改门面类的代码,更不要去继承或者代理门面类。
门面模式是负责“组合”子系统已有的功能,用于提供给现外部,满足需要,而不是添加新的实现。
我认为不需要创建过多的门面类,只让门面类去做封装那些较为复杂的流程操作。而子系统的一些简单的功能,调用环境仍然可以直接调用,而不是画蛇添足,为了设计模式而设计模式,没必要把一两步的操作也封装到门面类中。
五、实际使用
Shiro安全框架的Subject类就是一个非常典型门面类,组合了认证、授权、会话管理等多个复杂子系统。
经典的MVC模式就是经典的分层模式,Controller视为调用环境,不与DAO层直接交互。
分割线--------------------------------------------------------------------------------------------
下一篇:桥接设计模式13
刻意练习
(1)门面设计模式的定义
(2)门面设计模式核心心法
(3)优点、缺点
(4)实际用过的场景