Facade与Adapter模式应用

前言

作为设计模式第一篇随笔，首先以个人粗浅了解谈一谈何为设计模式。

 

简单来说，对于某一类新问题，可以使用前人为旧问题设计过的解决方案。将前人设计的模式应用到新问题上，不仅避免了许多可能碰壁的尝试，同时也是站在了巨人的肩膀之上。设计模式广泛应用于建筑学、工程学等学科；对于软件工程，设计模式也不例外。

软件中最困难的部分当属需求的变化。"需求发生了变化——它和死亡、纳税都是不可避免的三件事"——《设计模式解析》(Shalloway,Trott) 。设计模式的精髓在于关注于发现变化并封装变化，以便将变化限制在几个特定的类之中，修改一个类并不会影响到另一个类的正常工作。每个类担当起自己应有的责任，分工明确；只有在必要的时候才在类之间通信。

事实上设计模式非常适合使用类比的方法来说明。它本来就不是从代码本身孕育出来的。过分关注于代码的结果是导致混乱而不可读。设计模式是在失败中总结教训，可谓是由无数的尸体堆叠而成的丰碑。当然，假若我们掌握了设计模式的基本思路，不用走弯路，我们甚至可以自己推导出其中的一些内容。

 

设计模式初接触

为了提高代码的重用性与使用代码的效率，Facade(外观)（发音：佛萨德）与 Adapter(控制器) 模式应运而生。

1. Facade模式

问题背景：操作一台复杂的机器，没有一个初接触的人愿意了解机器每一个按钮的功能。假如我们只想完成“开机”，“运行1分钟”，“关机”的操作，应该如何在不了解机器细节的前提下完成操作呢？

创建一个类，内部提供“开机”“运行1分钟”“关机”三个方法，每个方法内对机器的操作进行具体的定义。