zoukankan      html  css  js  c++  java
  • 1.外观模式-facade

    初识外观模式

    定义

    为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用.也叫门面模式

    例子说明:一个电源总开关可以控制四盏灯、一个风扇、一台空调和一台电视机的启动和关闭。该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计。再者例如,一站式办理窗口,周报提交。

    结构和说明

    Facade:定义子系统的多个模块对外的高层接口,通常需要调用内部多个模块,从而把客户的请求代理给适当的子系统对象。

    模块:接受Facade对象的委派,真正实现功能,各个模块之间可能有交互。注意,Facade对象知道各个模块,但是各个模块不应该知道Facade对象.

    体会外观模式

    生活中的示例——组装电脑

    1:完全自己组装

    2:找专业装机公司组装

    代码生成的应用

    问题 如果现在客户端需要使用这个代码生成工具来生成需要的基础代码,该如何实现呢?

    不用模式的解决方案 直接参看代码示例 存在的问题 客户端为了使用生成代码的功能,需要与生成代码子系统内部的多个模块交互。

    使用模式的解决方案

    理解外观模式

    认识外观模式

    1:外观模式的目的 外观模式的目的不是给子系统添加新的功能接口,而是为了让外部减少与子系统内多个模块的交互,松散耦合,从而让外部能够更简单的使用子系统。

    2:使用外观跟不使用相比有何变化 Facade方便了客户端的调用、封装了系统内部的细节功能、实现功能的共享和复用

    3:有外观,但是可以不使用

    4:外观提供了缺省的功能实现

    5:外观模式的调用顺序示意图

     

    外观模式的实现

    1:把外观类当成一个辅助工具类实现

    2:Facade可以实现成为interface

     

    3:Facade实现成为interface的附带好处

    能够有选择性的暴露接口方法,尽量减少模块对子系统外提供的接口方法。

    4:Facade的方法实现 Facade的方法实现中,一般是负责把客户端的请求转发给子系统内部的各个模块进行处理,Facade的方法本身并不进行功能的处理,Facade的方法的实现只是实现一个功能的组合调用。

    外观模式的优缺点

    1:松散耦合

    实现了子系统与客户之间的松耦合关系,这使得子系统的组件变化不会影响到调用它的客户类,只需要调整外观类即可。

    2:简单易用

    对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式,客户代码将变得很简单,与之关联的对象也很少。

    3:更好的划分访问层次

    4:过多的或者是不太合理的Facade也容易让人迷惑

    思考外观模式

    外观模式的本质

    外观模式的本质是:封装交互,简化调用

    何时选用外观模式

    1:如果你希望为一个复杂的子系统提供一个简单接口的时候,可以考虑使用外观模式,使用外观对象来实现大部分客户需要的功能,从而简化客户的使用

    2:如果想要让客户程序和抽象类的实现部分松散耦合,可以考虑使用外观模式,使用外观对象来将这个子系统与它的客户分离开来,从而提高子系统的独立性和可移植性

    3:如果构建多层结构的系统,可以考虑使用外观模式,使用外观对象作为每层的入口,这样可以简化层间调用,也可以松散层次之间的依赖关系。

    总结

    1)根据“单一职责原则”,在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性,一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小,而达到该目标的途径之一就是引入一个外观对象,它为子系统的访问提供了一个简单而单一的入口。

    2)外观模式也是“迪米特法则”的体现,通过引入一个新的外观类可以降低原有系统的复杂度,外观类充当了客户类与子系统类之间的“第三者”,同时降低客户类与子系统类的耦合度。外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。

    3)外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行,外观类将客户端与子系统的内部复杂性分隔开,使得客户端只需要与外观对象打交道,而不需要与子系统内部的很多对象打交道。

    4)外观模式从很大程度上提高了客户端使用的便捷性,使得客户端无须关心子系统的工作细节,通过外观角色即可调用相关功能。

    5)不要试图通过外观类为子系统增加新行为 ,不要通过继承一个外观类在子系统中加入新的行为,这种做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道,而不是向子系统加入新的行为,新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现,不能通过外观类来实现。

    6) 抽象外观类的引入:外观模式最大的缺点在于有点(非抽象外观类)违背了“开闭原则”,

    当增加新的子系统或者移除子系统时需要修改外观类,可以通过引入抽象外观类在一定程度上解决该问题,客户端针对抽象外观类进行编程。对于新的业务需求,不修改原有外观类,而对应增加一个新的具体外观类,由新的具体外观类来关联新的子系统对象,同时通过修改配置文件来达到不修改源代码并更换外观类的目的

    代码地址: https://gitee.com/weixiaotao1992/DesignPatternsForJava

    其他参考:https://blog.csdn.net/hguisu/article/details/7533759?utm_source=blogxgwz0

  • 相关阅读:
    修改maven远程仓库为阿里的maven仓库(复制)
    Vue下iframe如何实现和父窗口的通信
    Vue在子组件内如何触发父组件的方法
    PhpStorm环境设置Debug
    史上最全的Excel数据编辑处理技巧(转)
    按钮样式
    字符和数字对齐的字体
    使用jquery控制只能输入数字,并且关闭输入法(转)
    Javascript中字符串转换成Date的方法
    MongoDB工具MagicMongoDBTool
  • 原文地址:https://www.cnblogs.com/weixiaotao/p/10368075.html
Copyright © 2011-2022 走看看