适配器模式： 将一个类的接口，转换成客户期望的另一个接口。适配器让原来接口不兼容的类可以合作无间。
适配器模式过程（客户无须知道被适配者接口是什么，而被适配者接口无须修改）：
- 客户通过目标接口调用适配器的方法对适配器发出请求;
- 适配器使用被适配者接口把请求转换成被失陪者的一个或多个调用接口;
- 客户接受收到调用的结果，但并未察觉这一切是适配器在起转换作用。
写在适配器之后： 适配器就由于并口转串口线，听起来很牛X，实际上辛辛苦苦只有自己知道。 在取舍之间，适配器连接不同接口之间。书中实例，老母鸡装土鸭，鸳鸯披上公鸡外衣。不同于装饰者，适配器负责转换，而不是继承。
外观模式： 提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
写在外观模式之后： 外观用于简化接口，连接动作。 也许比较像刚学程序时写的main函数，把动作一股脑儿堆一起; 好吧，外观到底是xx模式，它封装了其他接口，并保留原有的类动作，使用这个模式和C++中的模板一样 ── 方便。
设计原则
最少知识原则：只和你的密友谈话。
- 装饰者 ── 不改变接口，但加入责任。
- 适配器 ── 将一个接口转换成另一个接口。
- 外观 ── 让接口更简单。
后话： 所有模式都需要折衷，在抽象和速度之间的取舍，在空间和时间之间平衡…… 设计模式并不能使开发者写的代码执行效率更高，就有如写小程序时面向对象和过程的区别。 在FleaPHP论坛上也见到有人谈到，使用MVC模式的FLEA开发的系统比直接开发的系统承受并发的能力更低; 也有谈到新一代的QeePHP框架的效率。但有件事是不能否认的，设计模式使开发者更快速的开发，更友好的维护，至于效率，在折中之时也考验着开发者经验和能力。难道还因为Java比C效率第而放弃使用Java吗？
最新评论