facade 门面（外观）模式

场景分析

• 介绍一种场景，红烧鱼
• 假定红烧鱼包括：腌鱼，放入姜蒜、辣椒，煎鱼四个步骤，对应的类实体包括Fish, Ginger, Pepper, client 执行制作红烧鱼的动作时，可以单独一个一个调用，但如果包括十几个步骤时，直接让Client接触十几个类是比较粗暴的，可以在 Client 和 功能实体类之间，添加一层封装类-Facade，facade 将以功能单位进行封装划分，定义出包含若干环节的接口，如将红烧鱼的所有环节封装到fryFish 接口中
• 病人看病的案例，Client 即病人，需要与 挂号、门诊、取药、化验等直接打交道，乱、复杂，若出现一个 接待人员 facade 代替病人与各个系统打交道，则会减轻Client的复杂性
• java的三层开发模式

角色定义

• 门面角色
  • 客户端直接调用这个门面的方法，门面方法知晓子系统的功能和责任，且会将Client的请求委派到相应子系统中
• 子系统角色
  • 可以同时有一个或多个子系统，每个子系统都可以直接被Client 调用，也可被门面调用
  • 对于子系统而言，它并不知晓门面的存在，门面于它来讲，只是另一个Client而已

代码展示

• Fish

public class Fish {

    //把鱼腌一下
    public void pickleFish() {
        System.out.println("腌鱼");
    }

    //煎鱼
    public void fryFish() {
        System.out.println("煎鱼");
    }
}

• Ginger

/**
 * 姜
 */
public class Ginger {

    //放入姜片
    public void fryGinger(){
        System.out.println("热油放入姜片");
    }
}

• pepper

/**
 * 辣椒
 */
public class Pepper {
    //放入辣椒
    public void fryPepper() {
        System.out.println("炒辣椒");
    }
}

• 定义 facade

/**
 * 定义红烧鱼的facade
 */
public class FishFacade {

    //把材料准备好：鱼，辣椒，姜片
    private Fish fish;
    private Ginger ginger;
    private Pepper pepper;

    //准备材料
    public FishFacade() {
        //定义材料
        fish = new Fish();
        ginger = new Ginger();
        pepper = new Pepper();
    }

    //红烧鱼有若干步骤的，这里将所有分散步骤统一
    //该方法即所谓的 facade，以煎鱼为整体功能模块，封装了很多繁杂的环节，避免Client 直接各自调用
    //这里我们只是定义菜料，有可能中间还要让老婆帮忙系下围裙，或者让儿子买包盐去呢
    //总之是很多繁杂的逻辑
    public void fryFish() {
        //先把鱼腌一下
        fish.pickleFish();
        //放入辣椒
        pepper.fryPepper();
        //放入姜片
        ginger.fryGinger();
        //煎鱼
        fish.fryFish();
    }

}

• 定义 Demo

public class FacadeDemo {

    public static void main(String[] args) {
        
        FishFacade fishFacade = new FishFacade();
        
        //调用 facade
        fishFacade.fryFish();
        
        //如果不使用 facade 则 单步执行
        //腌鱼
        //fish.pickleFish();
        
        //油放姜片
        //ginger.fryGinger();
        
        //油放辣椒
        //pepper.fryPepper();
        
        //煎鱼
        //fish.fryFish();
    }

}

优缺点

• 优点
  • 对 Client 屏蔽了子系统的复杂性，降低了Client 与 子系统的直接交互
  • 实现子系统与 Client 的松耦合，使得子系统的变化不会影响到Client，只需更改 facade 类即可
  • 降低了大型软件系统的编译依赖性，简化了系统在不同平台之间的移植过程 ？？？
  • 只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统
• 缺点
  • 不能很好的限制Client对子系统的使用（Client可以直接调用子系统）
  • 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类和客户端代码，违背开闭原则

其他注意点

• 一个系统可以有多个外观类
  • 通常只需要一个外观类，且此外观类只有一个实例，即单例类，可以节省资源
  • 系统可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能
• 不要试图通过外观类为子系统增加新的行为
  • 不要通过继承一个外观类在子系统中加入新行为，外观的用意是为子系统提供一个集中化和简化的沟通渠道，而非向子系统加入新行为，新行为的增加应该通过修改原有子系统或增加新的子系统实现
• 外观模式与迪米特法则
  • 外观类充当了 Client 和 子系统之间的第三者，降低了Client 和 子系统的耦合
• 抽象外观类的引入
  • 外观类缺点违背了开闭原则，当增加新的系统或者移出子系统时需要修改外观类，可以通过引入抽象外观类解决一定的问题，对于新的业务需求，不修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类关联新的子系统对象

参考：http://blog.csdn.net/xingjiarong/article/details/50066133