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

巴特西

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

思考题

外观模式

特点

区别 `P270`

设计原则

优点

缺点

遵循最少知识原则的方针

思考题

所思所想

最新文章

热门文章

巴特西

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

思考题

外观模式

特点

区别 P270

设计原则

优点

缺点

遵循最少知识原则的方针

思考题

所思所想

最新文章

热门文章

区别 `P270`