外观模式

外观模式的目的不是给子系统添加新的功能接口，而是为了让外部减少与子系统多个模块之间的交互，松散耦合，从而让外部能够更简单的使用子系统。

Facade模式方便了客户端的调用、封装了系统内部的细节功能、实现功能的共享和复用。
但是需要注意的是过多的或者不太合理的Facade也容易让人迷惑。

外观模式的本质是：封装交互，简化应用。
外观模式的设计原则是“最少知识原则”。

何时选用外观模式？
如果你希望为一个复杂的子系统提供一个简单接口的时候，可以考虑使用外观模式，使用外观模式来实现大部分的客户的需要的功能，从而简化客户的使用。
吐过想要让客户程序和抽象类的实现部分松散耦合，可以考虑使用外观模式，使用外观对象来将这个子系统与它的客户分离开来，从而提高子系统的独立性和可移植性。
如果构建多层结构的系统，可以考虑使用外观模式，使用外观对象作为每层的入口，这样就可以简化层之间的调用，也可以松散层次之间的耦合。典型使用就是MVC模式开发的service层。

下面是一个小例子：
说现在有一个可以“组装电脑”的子系统，细分为主机模块和显示屏模块。代码如下：

public interface AModule {
	void facadeA();
}

public class AModuleImpl implements AModule {

	@Override
	public void facadeA() {
		System.out.println("我是这台电脑的主机，负责运算");
	}

}

public interface BModule {
	void facadeB();
}

public class BModuleImpl implements BModule {

	@Override
	public void facadeB() {
		System.out.println("我是这台电脑的显示屏，负责视图");
	}

}

客户端的要求很简单，只需要服务端提供一台完整的电脑给我即可，客户端并不想知道这个电脑怎么组装。于是外观类出现了：

/**
 * 外观模式的facade，将模块目前已经存在的功能进行组装，
 * 并且暴露给Client，实现了客户端和业务模块之间的松耦合
 * (注意没有杜绝耦合，因为Client依然依赖Facade)
 * 
 * Facade的另外一个优势在于实现了代码的重用，大量的Client只需要使用Facade就可以了
 * 
 * 更好的方式是将facade作为借口暴露给客户端，这样的好处是可以设置"外观"的功能，这里为了简化演示就直接实现为普通java类
 * @author rao
 *
 */
public class Facade {
	public void createPC(){
		// 电脑主机
		AModule aModule = new AModuleImpl();
		aModule.facadeA();
		// 电脑显示屏
		BModule bModule = new BModuleImpl();
		bModule.facadeB();
	}
}

这样做客户端就可以轻而易举的拿到一台电脑了！

public class Client {
	public static void main(String[] args) {
		Facade facade = new Facade();
		facade.createPC();
	}
}