Head First 设计模式 —— 08. 外观 (Facade) 模式

思考题

想想看，你在 JavaAPI 中遇到过哪些外观，你还希望 Java 能够新增哪些外观？ P262

• println、log 日志接口、JDBC 接口
• 突然让想感觉想不出来，各种 API 都用得挺顺的，没有太麻烦的使用

外观模式

提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。 P264

特点

• 提供简化的接口的同时，依然将系统完整的功能暴露出来 P260
• 将客户从组件的子系统中解耦 P260
• 意图是提供子系统的一个简化接口 P260

区别 P270

• 适配器模式：将一个对象包装起来以改变其接口
• 装饰器模式：将一个对象包装起来以增加新的行为和责任
• 外观模式：将一群对象“包装”起来以简化其接口

设计原则

最少知识原则：只和你的密友谈话。即减少对象之间的交互，减少类的耦合。 P265

优点

• 减少软件的维护成本 P267

缺点

• 导致制造更多的“包装”类 P267
• 导致增加复杂度和开发时间 P267
• 降低运行时的性能 P267

遵循最少知识原则的方针

对于任何对象，在该对象的方法内，我们只应该调用属于以下范围的方法： P266

• 该对象本身
• 被当作方法的参数而传递进来的对象
• 此方法所创建或实例化的任何对象
• 对象的任何组件

由前三条可知：不要调用其他方法返回结果的方法

思考题

这些类有没有违反最少知识原则？请说明原因。 P268

public class House {
    WeatherStation station;
    
    // 其他的方法和构造器
    
    public float getTemp() {
        return station.getThermometer().getTemperature();
    }
    // 违反了最少知识原则
    // 调用了方法返回结果的方法
}

public class Houst {
    WeatherStation station;

    // 其他的方法和构造器
    
    public float getTemp() {
        Thermometer thermometer = station.getThermometer();
        return getTempHelper(thermometer);
    }
    // 没有违反最少知识原则
    // 只调用了对象的组件以及对象本身的方法
    
    public float getTempHelper(Thermometer thermometer) {
        return thermometer.getTemperature();
    }
    // 只调用了参数
}

所思所想

• 大部分接口功能的封装应该都算使用了外观模式。比如说下单操作，对外只暴露了一个下单接口，但内部其实有大量的子组件调用（购物车接口、运费计算接口、优惠券接口、地址接口、下单中间件、物流接口等）。再比如一个简单println，内部就包含了并发控制、异常捕获、调用BufferedWriter对象进行输出控制等。

本文首发于公众号：满赋诸机（点击查看原文） 开源在 GitHub ：reading-notes/head-first-design-patterns