关于设计模式: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