Java设计模式之java外观模式详解

目录
  • 模式动机
  • 模式定义
  • 模式结构
  • 角色
  • 模式分析
  • 典型的外观角色代码
  • 外观模式实例与解析
    • 实例一:电源总开关
    • 实例二:文件加密
  • 模式优缺点
    • 优点
    • 缺点
  • 模式适用环境
  • 源码分析外观模式的典型应用
    • (1) 外观模式应用于JDBC数据库操作
    • (2) Session外观模式是外观模式在Java EE框架中的应用
  • 模式扩展
    • 一个系统有多个外观类
    • 不要试图通过外观类为子系统增加新行为
    • 外观模式与迪米特法则
    • 抽象外观类的引入
  • 总结
  • 参考文章
  • 总结

模式动机

引入外观角色之后,用户只需要直接与外观角色交互,用户与子系统之间的复杂关系由外观角色来实现,从而降低了系统的耦合度。

模式定义

外观模式是一种使用频率非常高的结构型设计模式,它通过引入一个外观角色来简化客户端与子系统之间的交互,为复杂的子系统调用提供一个统一的入口,降低子系统与客户端的耦合度,且客户端调用非常方便。

外观模式又称为门面模式,它是一种对象结构型模式。外观模式是迪米特法则的一种具体实现,通过引入一个新的外观角色可以降低原有系统的复杂度,同时降低客户类与子系统的耦合度。

模式结构

角色

  • Facade(外观角色):在客户端可以调用它的方法,在外观角色中可以知道相关的(一个或者多个)子系统的功能和责任;在正常情况下,它将所有从客户端发来的请求委派到相应的子系统去,传递给相应的子系统对象处理。
  • SubSystem(子系统角色):在软件系统中可以有一个或者多个子系统角色,每一个子系统可以不是一个单独的类,而是一个类的集合,它实现子系统的功能;每一个子系统都可以被客户端直接调用,或者被外观角色调用,它处理由外观类传过来的请求;子系统并不知道外观的存在,对于子系统而言,外观角色仅仅是另外一个客户端而已。

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

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

模式分析

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

外观模式也是“迪米特法则”的体现,通过引入一个新的外观类可以降低原有系统的复杂度,同时降低客户类与子系统类的耦合度。

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

外观模式的目的在于降低系统的复杂程度。

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

典型的外观角色代码

 public class Facade
  {
      private SubSystemA obj1 = new SubSystemA();
      private SubSystemB obj2 = new SubSystemB();
      private SubSystemC obj3 = new SubSystemC();
      public void method()
      {
          obj1.method();
          obj2.method();
         obj3.method();
     }
 }

外观模式实例与解析

实例一:电源总开关

现在考察一个电源总开关的例子,以便进一步说明外观模式。为了使用方便,一个电源总开关可以控制四盏灯、一个风扇、一台空调和一台电视机的启动和关闭。通过该电源总开关可以同时控制上述所有电器设备,使用外观模式设计该系统

//子系统角色
public class Fan
{
    private Fan(){}
    private static  Fan instance;
    //静态代码块中创建单例对象
    static {
        instance=new Fan();
    }
    public static  Fan getInstance()
    {
        return instance;
    }
    public void on()
    {
        System.out.println("风扇开");
    }
    public  void off()
    {
        System.out.println("风扇关");
    }
}
//子系统角色
public class Light
{
    //静态常量
    private static  Light  instance=new Light();;
    //构造器私有化
    private  Light(){};
  //共有静态方法,返回一个实例对象
    public  static  Light getInstance()
    {
        return instance;
    }
    public  void on()
    {
        System.out.println("灯开");
    }
    public  void  off()
    {
        System.out.println("灯关");
    }
}

//外观角色
public class GeneralSwitchFaced
{
    private Light light;
    private  Fan fan;
  public GeneralSwitchFaced()
    {
        light=Light.getInstance();
        fan=Fan.getInstance();
    }
    public void on()
    {
        light.on();
        fan.on();
    }
    public void off()
    {
        light.off();
        fan.off();
    }
}
//测试
public class Test
{
    @org.junit.Test
    public void test()
    {
        GeneralSwitchFaced faced=new GeneralSwitchFaced();
        faced.on();
        faced.off();
    }
}

实例二:文件加密

某系统需要提供一个文件加密模块,加密流程包括三个操作,分别是读取源文件、加密、保存加密之后的文件。读取文件和保存文件使用流来实现,这三个操作相对独立,其业务代码封装在三个不同的类中。现在需要提供一个统一的加密外观类,用户可以直接使用该加密外观类完成文件的读取、加密和保存三个操作,而不需要与每一个类进行交互,使用外观模式设计该加密模块。

通过外观角色的一个方法,封装了三个独立的操作过程,即将文件的加密过程封装在了外观角色的文件加密方法中,客户通过调用该方法即可完成对文件的加密,无需挨个调用三个独立的操作

模式优缺点

优点

  • 对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式,客户代码将变得很简单,与之关联的对象也很少。
  • 实现了子系统与客户之间的松耦合关系,这使得子系统的组件变化不会影响到调用它的客户类,只需要调整外观类即可。
  • 降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程,因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象
  • 只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类。

缺点

  • 不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
  • 在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。

模式适用环境

  • 当要为一个复杂子系统提供一个简单接口时可以使用外观模式。该接口可以满足大多数用户的需求,而且用户也可以越过外观类直接访问子系统。
  • 客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦,可以提高子系统的独立性和可移植性。
  • 在层次化结构中,可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。

源码分析外观模式的典型应用

(1) 外观模式应用于JDBC数据库操作

 public class JDBCFacade {
     private Connection conn=null;
     private Statement statement=null;
     public void open(String driver,String jdbcUrl,String userName,String userPwd) {
         ......
      }
      public int executeUpdate(String sql) {
         ......
      }
     public ResultSet executeQuery(String sql) {
         ......
     }
     public void close() {
         ......
     }
 }

(2) Session外观模式是外观模式在Java EE框架中的应用

模式扩展

一个系统有多个外观类

在外观模式中,通常只需要一个外观类,并且此外观类只有一个实例,换言之它是一个单例类。在很多情况下为了节约系统资源,一般将外观类设计为单例类。当然这并不意味着在整个系统里只能有一个外观类,在一个系统中可以设计多个外观类,每个外观类都负责和一些特定的子系统交互,向用户提供相应的业务功能。

不要试图通过外观类为子系统增加新行为

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

外观模式与迪米特法则

外观模式创造出一个外观对象,将客户端所涉及的属于一个子系统的协作伙伴的数量减到最少,使得客户端与子系统内部的对象的相互作用被外观对象所取代。外观类充当了客户类与子系统类之间的“第三者”,降低了客户类与子系统类之间的耦合度,外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。

抽象外观类的引入

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

总结

参考文章

外观模式

java设计模式之外观模式(Facade)

总结

本篇文章就到这里了,希望能够给你带来帮助,也希望您能够多多关注我们的更多内容!

时间: 2021-09-14

Java设计模式之外观模式(Facade模式)介绍

外观模式(Facade)的定义:为子系统中的一组接口提供一个一致的界面. Facade一个典型应用就是数据库JDBC的应用,如下例对数据库的操作: 复制代码 代码如下: public class DBCompare { Connection conn = null; PreparedStatement prep = null; ResultSet rset = null; try { Class.forName( "<driver>" ).newInstance(); co

23种设计模式(8) java外观模式

23种设计模式第八篇:java外观模式 定义: 为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用. 角色: 1.外观(Facade)角色 :客户端可以调用这个角色的方法.此角色知晓相关子系统的功能和责任.在正常情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去. 2.子系统(SubSystem)角色 :可以同时有一个或者多个子系统.每个子系统都不是一个单独的类,而是一个类的集合.每个子系统都可以被客户端直接调用,或者被外观角

Java设计模式详解之门面模式(外观模式)

门面模式(Facade Pattern)也叫外观模式,它隐藏系统的复杂性,并向客户端提供一个可以访问系统的接口.这种类型的设计模式属于结构型模式,它向现有的系统添加一个接口,来隐藏系统的复杂性,为子系统中的一组接口提供了一个统一的高层访问接口,这个接口使得子系统更容易被访问或使用.这种模式涉及到一个单一的类,该类提供了客户端请求的简化方法和对现有系统类方法的委托调用. 简而言之,就是把一堆复杂的流程封装成一个接口供给用户更简单的使用,这个设计模式里有三个角色: 1)门面角色( facade ):

java设计模式之外观模式学习笔记

外观模式: 又称门面模式: 外观Facade为子系统的一组接口提供一个一致界面,使得这组子系统易于使用(通过引入一个新的外观角色降低原系统复杂度,同时降低客户类与子系统的耦合度). 图片来源: 设计模式: 可复用面向对象软件的基础. 实现 案例需求: 租房 有过自己找房租房经历的同学能够体会得到找房是件很痛苦的事, 不光要挨个小区跑而且还要跟(二)房东讨价还价. 于是后来学聪明了, 不再自己挨门挨户的磨嘴皮子, 而是直接找像链家.我爱我家这样的房屋中介, 他们手上握有一定的房源, 我们只需付给他

java设计模式之外观模式(Facade)

概述 外部与内部子系统通信时必须通过的一个统一的外观模式对象进行,就是外观模式,也称门面模式.一般而言,Facade模式是为了降低客户端与实现化层之间的依赖性.外观模式的用意是为子系统提供一个集中化和简化的沟通渠道. UML类图 在上面的UML图中,出现三个角色: 客户端角色(Client):用户通过客户端来调用外观模式的类,从而来操作子系统: 外观角色(Facade):客户端可以调用这个类,此类中包含了调用子系统中具体的功能: 子系统角色(Module):定义了子系统中具体的单个功能: 代码示

C++设计模式之外观模式(Facade)

外观模式应该是程序员最下意识用的一种模式,比如我们习惯性的对复杂系统做一个封装接口.外观模式其本质是对一堆复杂对象和应用的接口抽象,对它们进行封装隔离,对于调用者来说只需要关系接口的实现,而不需要知道内部有哪些对象和调用. 作用 为模块的一组接口提供一致的界面,定义了一个高层接口,这个接口使得这一模块更加容易使用. 类视图 实现 //复杂或多对象 class objectOne { public void operator() { cout<<"operator one\n"

PHP设计模式(九)外观模式Facade实例详解【结构型】

本文实例讲述了PHP设计模式:外观模式Facade.分享给大家供大家参考,具体如下: 1. 概述 外观模式,我们通过外观的包装,使应用程序只能看到外观对象,而不会看到具体的细节对象,这样无疑会降低应用程序的复杂度,并且提高了程序的可维护性. 例子1:一个电源总开关可以控制四盏灯.一个风扇.一台空调和一台电视机的启动和关闭.该电源总开关可以同时控制上述所有电器设备,电源总开关即为该系统的外观模式设计. 2. 问题 为了降低复杂性,常常将系统划分为若干个子系统.但是如何做到各个系统之间的通信和相互依

PHP设计模式之外观模式(Facade)入门与应用详解

本文实例讲述了PHP设计模式之外观模式(Facade)入门与应用.分享给大家供大家参考,具体如下: 这个外观模式,就是通过在必需的逻辑和方法的集合前创建简单的外观接口,并且还会隐藏了调用对象的复杂性,它和建造者模式非常相似,建造者模式一般是简化对象的调用的复杂性,但是外观模式一般是简化含有很多逻辑步骤和方法调用的复杂性. 来看下实例,先来描述下: 设计一个User类,里面有getUser获取用户信息接口 在使用getUser这个接口的时候,需要设置用户的用户名和用户年龄 所以在正常情况下,调用g

Python设计模式之外观模式实例详解

本文实例讲述了Python设计模式之外观模式.分享给大家供大家参考,具体如下: 外观模式(Facade Pattern):为子系统中的一组接口提供一个一致界面,此模式定义一个高层接口,使得子系统更加容易使用 下面是一个外观模式的demo: #!/usr/bin/env python # -*- coding:utf-8 -*- __author__ = 'Andy' """ 大话设计模式 设计模式--外观模式 facade_pattern.py 外观模式(Facade Pat

Java设计模式之备忘录模式_动力节点Java学院

定义:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态.这样就可以将该对象恢复到原先保存的状态 类型:行为类 类图: 我们在编程的时候,经常需要保存对象的中间状态,当需要的时候,可以恢复到这个状态.比如,我们使用Eclipse进行编程时,假如编写失误(例如不小心误删除了几行代码),我们希望返回删除前的状态,便可以使用Ctrl+Z来进行返回.这时我们便可以使用备忘录模式来实现. 备忘录模式的结构 发起人:记录当前时刻的内部状态,负责定义哪些属于备份范围的状态,负责创建和

JAVA设计模式之建造者模式原理与用法详解

本文实例讲述了JAVA设计模式之建造者模式定义与用法.分享给大家供大家参考,具体如下: 建造者模式:将复杂对象的构造与它的实现相分离,让相同的构建过程可以创建不同的对象. 适用场合: 复杂对象的算法应该独立于该对象的组成部分或当构造过程允许被构造不同的对象时. 组成角色: 1 创建者(Builder)接口:为创建一个对象的对应部件所指定抽象接口. 2 具体创建者(ConcreteBuilder):实现Builder的接口以构造对象的各个部件. 3 具体创建者管理对象(Director):使用Bu

java设计模式之工厂模式实例详解

本文实例讲述了java设计模式之工厂模式.分享给大家供大家参考,具体如下: 工厂模式(factory) 涉及到4个角色:抽象工厂类角色,具体工厂类角色,抽象产品类角色和具体产品类角色. 抽象工厂类角色使用接口或者父类来描述工厂的行为, 具体工厂类角色负责创建某一类型的产品对象. 抽象产品类可以使用接口或者父类来描述产品对象的行为特征. 具体产品类就是某一具体的对象. 工厂模式不同于静态工厂模式的地方: 工厂模式在工厂类也实现了多态,而不仅仅是在产品对象上实现多态. 它可以应对不同类型的产品对应一