设计模式-Facade(外观).pptVIP

Facade——外观模式 引子 在真实的应用系统中，一个子系统可能由很多类组成。子系统的客户为了满足它们的需要，需要和子系统中的一些类进行交互。客户和子系统的类进行直接的交互会导致客户端对象和子系统之间高度耦合。如下图所示： 示意图 问题 在软件开发中，客户程序经常会与复杂的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。 那么如何简化客户程序与子系统之间的交互接口？ 如何将复杂系统的内部子系统与客户程序之间的依赖解耦？ 引入外观模式 外观模式为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度和依赖，这使得子系统更易于使用和管理。外观是一个能为子系统和客户提供简单接口的类。当正确地应用外观时，客户不再直接与子系统中的类交互，而是与外观交互。外观承担与子系统中类交互的责任。实际上，外观是子系统与客户的接口，这样外观模式降低了子系统和客户的耦合度。 如下图： 示意图 外观模式 外观对象隔离了客户和子系统对象，从而降低了耦合度。当子系统中的类进行改变时，客户端不会像以前一样受到影响。尽管客户使用由外观提供的简单接口，但是当需要的时候，客户端还是可以视外观不存在，直接访问子系统中的底层次的接口。在这种情况下，它们之间的依赖/耦合度和原来一样。 外观模式也是由代理模式发展而来的，与代理模式类似，代理模式是一对一的代理，而外观模式是一对多的代理。与装饰模式不同的是，装饰模式为对象增加功能，而外观模式则是提供一个简化的调用方式。一个系统可以有多个外观类，每个外观类都只有一个实例，可以使用单例模式实现。 生活中的例子 当消费者按照目录采购时，则体现了一个外观模式。消费者拨打一个号码与客服代表联系，客服代表则扮演了这个外观，他包含了与订货部、收银部和送货部的接口。 代码实现： 我们平时的开发中其实已经不知不觉的在用Facade模式，现在来考虑这样一个抵押系统，当有一个客户来时，有如下几件事情需要确认：1.到银行子系统查询他是否有足够多的存款，2.到信用子系统查询他是否有良好的信用。 3.到贷款子系统查询他有无贷款劣迹。 只有这三个子系统都通过时才可进行抵押。我们先不考虑Facade模式，那么客户程序就要直接访问这些子系统，分别进行判断。类结构图下： 无外观类图解： 可以看到，在不用Facade模式的情况下，客户程序与三个子系统都发生了耦合，这种耦合使得客户程序依赖于子系统，当子系统变化时，客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口，这个接口简化了客户程序的判断操作。看一下引入Facade模式后的类结构图： 增加外观类 可以看到引入Fa?ade模式后，客户程序只与Mortgage发生依赖，也就是Mortgage屏蔽了子系统之间的复杂的操作，达到了解耦内部子系统与客户程序之间的依赖。   .NET架构中的Facade模式 ????? 总结 外观模式为复杂子系统提供了一个简单接口，并不为子系统添加新的功能和行为。 外观模式实现了子系统与客户之间的松耦合关系。 外观模式没有封装子系统的类，只是提供了简单的接口。如果应用需要，它并不限制客户使用子系统类。因此可以在系统易用性与通用性之间选择。 外观模式注重的是简化接口，它更多的时候是从架构的层次去看整个系统，而并非单个类的层次。