Skip to content

Latest commit

 

History

History
110 lines (75 loc) · 3.84 KB

Java设计模式之门面模式.md

File metadata and controls

110 lines (75 loc) · 3.84 KB

Java设计模式之门面模式

[TOC]

介绍

门面模式(Facade Pattern)也叫做外观模式,是一种比较常用的封装模式

要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口,使得子系统更易于使用。

门面模式注重“统一的对象”,也就是提供一个访问子系统的接口,除了这个接口不允许有任何访问子系统的行为发生

实例解释

比如说送礼物,那么会有这样的步骤:在店里购买,确定目标地址,打车过去,送出礼物。

看似挺简单,礼物多了还是麻烦,比如到了情人节,为了大海捞针,给十个女孩子送礼物,都要这样跑一遍,你不要累死,更别说你要发个广告信啥的,一下子发 1 千万封邮件,那不就完蛋了?

原始的实现方式

不仅仅有四个子系统(实现步骤),而且还要求实现顺序,否则不能超过送出啊

/**
 * @author www.haotianyi.win
 * @version V1.0
 * @Description: 送礼物
 * @date 2017/4/6 20:25
 */
public class PullGift {

    public void buyGift(){
        System.out.println("购买礼物");
    }

    public void location(){
        System.out.println("确定目标地址");
    }

    public void go(){
        System.out.println("去美女家");
    }

    public void giveGift(){
        System.out.println("送礼物");
    }
}

客户端实现:

public class Client {
    public static void main(String[] args) {
        PullGift pullGift = new PullGift();
        pullGift.buyGift();
        pullGift.location();
        pullGift.go();
        pullGift.giveGift();
    }
}

使用门面模式

新增一个Fcade类,来封装PullGift的方法:

public class Facade {

    private PullGift mPullGift;

    public Facade() {
        mPullGift = new PullGift();
        mPullGift.buyGift();
        mPullGift.location();
        mPullGift.go();
        mPullGift.giveGift();
    }
}

使用场景

  1. 为一个复杂的模块或子系统提供一个供外界访问的接口
  2. 子系统相对独立——外界对子系统的访问只要黑箱操作即可

比如利息的计算问题,没有深厚的业务知识和扎实的技术水平是不可能开发出该子系统的,但是对于使用该系统的开发人员来说,他需要做的就是输入金额以及存期,其他的都不用关心,返回的结果就是利息,这时候,门面模式是非使用不可了。

  1. 预防低水平人员带来的风险扩散

比如一个低水平的技术人员参与项目开发,为降低个人代码质量对整体项目的影响风险,一般的做法是“画地为牢”,只能在指定的子系统中开发,然后再提供门面接口进行访问操作。

优缺点

优点:

  1. 减少系统的相互依赖

想想看,如果我们不使用门面模式,外界访问直接深入到子系统内部,相互之间是一种强耦合关系,你死我就死,你活我才能活,这样的强依赖是系统设计所不能接受的,门面模式的出现就很好地解决了该问题,所有的依赖都是对门面对象的依赖,与子系统无关。

  1. 提高了灵活性

依赖减少了,灵活性自然提高了。不管子系统内部如何变化,只要不影响到门面对象,任你自由活动。

  1. 提高安全性

想让你访问子系统的哪些业务就开通哪些逻辑,不在门面上开通的方法,你休想访问到。

缺点: 门面模式最大的缺点就是不符合开闭原则,对修改关闭,对扩展开放,看看我们那个门对象吧,它可是重中之重,一旦在系统投产后发现有一个小错误,你怎么解决?完全遵从开闭原则,根本没办法解决。继承?覆写?都顶不上用,唯一能做的一件事就是修改门面角色的代码,这个风险相当大,这就需要大家在设计的时候慎之又慎,多思考几遍才会有好收获