标签：调用 [] hit 实现 important oid 不同 article 并且
外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。
外观模式不只是简化了接口，也将客户从组件的子系统中解耦。
外观和适配器可以包装许多类，但是外观强调的是简化接口，而适配器是为了将接口转换成不同的接口。
外观角色（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(); } }
优点：
缺点：
一个系统有多个外观类：在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。在很多情况下为了节约系统资源，一般将外观类设计为单例类。当然这并不意味着在整个系统里只能有一个外观类，在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。不要试图通过外观类为子系统增加新行为：不要通过继承一个外观类在子系统中加入新的行为，这种做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统加入新的行为，新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。外观模式与迪米特法则：外观模式创造出一个外观对象，将客户端所涉及的属于一个子系统的协作伙伴的数量减到最少，使得客户端与子系统内部的对象的相互作用被外观对象所取代。外观类充当了客户类与子系统类之间的“第三者”，降低了客户类与子系统类之间的耦合度，外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。抽象外观类的引入：
外观模式最大的缺点在于违背了“开闭原则”，
当增加新的子系统或者移除子系统时需要修改外观类，可以通过引入抽象外观类在一定程度上解决该问题，客户端针对抽象外观类进行编程。对于新的业务需求，不修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改源代码并更换外观类的目的。UML:
参考：
http://blog.csdn.net/hguisu/article/details/7533759
http://www.cnblogs.com/JsonShare/p/7121383.html
标签：调用 [] hit 实现 important oid 不同 article 并且
原文地址：http://www.cnblogs.com/xcsn/p/7242446.html
