一、定义
外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
外观模式不只是简化了接口，也将客户从组件的子系统中解耦。
外观和适配器可以包装许多类，但是外观强调的是简化接口，而适配器是为了将接口转换成不同的接口。
二、结构
外观角色（Facade）：是模式的核心，他被客户client角色调用，知道各个子系统的功能。同时根据客户角色已有的需求预订了几种功能组合
子系统角色（Subsystem classes）：实现子系统的功能，并处理由Facade对象指派的任务。对子系统而言，facade和client角色是未知的，没有Facade的任何相关信息；即没有指向Facade的实例。
客户角色（client）：调用facade角色获得完成相应的功能。
三、实现
class Program
{
static void Main(string[] args)
{
//----晚上下班回到家----
//开灯光
ILight light = new Light();
light.On();
//看电视
ITV tv = new TV();
tv.On();
//-----睡觉-----
//关灯光
light.Off();
//关电视
tv.Off(); Console.WriteLine("==== 最近有钱换智能家居了 ===="); ISmartHome smarthome = new SmartHome();
//----晚上下班回到家----
smarthome.On();
//-----睡觉-----
smarthome.Off();
}
} /// <summary>
/// 灯光接口
/// </summary>
public interface ILight
{
/// <summary>
/// 开灯
/// </summary>
void On();
/// <summary>
/// 关灯
/// </summary>
void Off();
} /// <summary>
/// 灯光接口实现类
/// </summary> public class Light : ILight
{
public void On()
{
Console.WriteLine("打开灯");
} public void Off()
{
Console.WriteLine("关闭灯");
}
} /// <summary>
/// 电视接口
/// </summary>
public interface ITV
{
/// <summary>
/// 开机
/// </summary>
void On();
/// <summary>
/// 关机
/// </summary>
void Off();
} /// <summary>
/// 智能家居总开关接口
/// </summary>
public interface ISmartHome
{
/// <summary>
/// 开灯
/// </summary>
void On();
/// <summary>
/// 关灯
/// </summary>
void Off();
}
public class TV : ITV
{
public void On()
{
Console.WriteLine("打开电视");
} public void Off()
{
Console.WriteLine("关闭电视");
}
} public class SmartHome : ISmartHome
{
private ILight light = new Light();
private ITV tv = new TV(); public void On()
{
light.On();
tv.On();
}
public void Off()
{
light.Off();
tv.Off();
}
}
四、适用场景
在以下情况下可以考虑使用外观模式：
(1)设计初期阶段，应该有意识的将不同层分离，层与层之间建立外观模式。
(2) 开发阶段，子系统越来越复杂，增加外观模式提供一个简单的调用接口。
(3) 维护一个大型遗留系统的时候，可能这个系统已经非常难以维护和扩展，但又包含非常重要的功能，为其开发一个外观类，以便新系统与其交互。
五、优缺点
优点：
1）对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观模式，客户代码将变得很简单，与之关联的对象也很少。
2）实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的客户类，只需要调整外观类即可。
3）降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程，因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
4）只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类。
缺点：
1） 不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
2） 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
六、模式扩展
参考：
http://blog.csdn.net/hguisu/article/details/7533759
http://www.cnblogs.com/JsonShare/p/7121383.html