思考题
想想看，你在 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