被说了很多遍的设计模式---外观模式

[把你的理性思维慢慢变成条件反射]

本文，我们讲介绍外观模式，文章主题结构与上文一致。惯例，先来看看我们示例工程的环境：

-------------------------------------------------------------------------------------------------------------------------------------

经典问题：

代理商，中间商，第三方中介等功能整合性应用。本文以“装修公司”为例说明。

思路分析：

要点一：功能存在多个

要点二：功能需要整合

要点三：对调用方透明

示例工程：

错误写法：

创建DecorativeMaterials1.java，DecorativeMaterials2.java，DecorativeMaterials3.java，DecorativeMaterials4.java四个文件，具体内容如下：

package com.csdn.ingo.gof_Facade;public class DecorativeMaterials1 {public void select() {System.out.println("select DecorativeMaterials1");}public void buy() {System.out.println("buy DecorativeMaterials1");}
}

创建Window.java文件，具体内容如下：

package com.csdn.ingo.gof_Facade;public class Window {public static void main(String[] args) {DecorativeMaterials1 dm1 = new DecorativeMaterials1();DecorativeMaterials2 dm2 = new DecorativeMaterials2();DecorativeMaterials3 dm3 = new DecorativeMaterials3();DecorativeMaterials4 dm4 = new DecorativeMaterials4();dm1.select();dm2.select();dm3.select();dm4.select();dm1.buy();dm2.buy();dm3.buy();dm4.buy();}
}

错误原因：

调用方需要逐一调用被动方的工程，承担了过多职责。代码书写方式过于臃肿。

推荐写法：

创建DecorateCompany.java文件，具体内容如下：

package com.csdn.ingo.gof_Facade.one;public class DecorateCompany {DecorativeMaterials1 dm1;DecorativeMaterials2 dm2;DecorativeMaterials3 dm3;DecorativeMaterials4 dm4;public DecorateCompany() {dm1 = new DecorativeMaterials1();dm2 = new DecorativeMaterials2();dm3 = new DecorativeMaterials3();dm4 = new DecorativeMaterials4();}public void buy(){dm1.buy();dm2.buy();dm3.buy();dm4.buy();}public void select(){dm1.select();dm2.select();dm3.select();dm4.select();}
}

创建DecorativeMaterials1.java，DecorativeMaterials2.java，DecorativeMaterials3.java，DecorativeMaterials4.java四个文件，具体内容如下：

package com.csdn.ingo.gof_Facade.one;public class DecorativeMaterials1 {public void select() {System.out.println("select DecorativeMaterials1");}public void buy() {System.out.println("buy DecorativeMaterials1");}
}

创建Window.java文件，具体内容如下：

package com.csdn.ingo.gof_Facade.one;public class Window {public static void main(String[] args) {DecorateCompany dc = new DecorateCompany();dc.select();dc.buy();}
}

模式总结：

标准外观模式UML结构图：

模式总结：

外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

组成部分：Facade（外观抽象类），SubSystem*（具体子系统）两大部分组成。

特别提醒：这里的子系统是一个广义概念，它可以是一个类，模块，甚至是一个系统。

模板功能扩展：

由结构图可以看出Facade只有一个，其他所有SubSystem都继承，实现该类。但是在某些场景下，只有一个外观类，其在接口数量上可能是不够在场景中使用的。因此，作为扩展，我们可以在Facade之上，再抽象出一个抽象类，供客户端使用，这种效果，类似于多次继承。

反思：

应用场景：

在设计一开始需要考虑分层设计时，在层与层之间建立。
在开发过程中，随着模型的不断重构，精炼，适当引入，能够帮助实现更加简洁优化的代码实现。
对已经有的功能，进行封装，维护等等。
为当前系统向外提供统一的，简单的功能接口时。
为减少各个组件之间的耦合关系时。

优点：

屏蔽了子系统的实现细节与过程，有效优化了客户端的调用。
降低了各个组件之间的耦合关系，同事不影响客户端的功能使用。

缺点：

过多的屏蔽，可能会导致客户端的灵活性降低。
Facade抽象类需要精心设计，可能出现随着功能需求演进，需要新功能加入时，可能违背“开闭原则”，修改Facade抽象类的可能。

-------------------------------------------------------------------------------------------------------------------------------------

至此，被说了很多遍的设计模式---外观模式结束

参考资料：

图书：《大话设计模式》

其他博文：http://blog.csdn.NET/lovelion/article/details/7563445