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

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

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

操作系统：win7 x64

其他软件：eclipse mars，jdk7

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

经典问题：

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

思路分析：

要点一：功能存在多个

要点二：功能需要整合

要点三：对调用方透明

示例工程：

错误写法：

创建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之上，再抽象出一个抽象类，供客户端使用，这种效果，类似于多次继承。

反思：

应用场景：

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

优点：

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

缺点：

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

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

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

参考资料：

图书：《大话设计模式》

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