标签:alt art ring out src 耦合度 高度 简化 责任
什么是外观模式?
外观模式(Facade),为子系统中的一组接口提供一个一致的界面,定义一个高层接口,这个接口使得这一子系统更加easy使用。
简单点说:外观模式是一种使用频率很高的结构型设计模式。它通过引入一个外观角色来简化client与子系统之间的交互。为复杂的子系统调用提供一个统一的入口,减少子系统与client的耦合度,且client调用很方便。
概述:
在真实的应用系统中。一个子系统可能由非常多类组成。子系统的客户为了它们的须要。须要和子系统中的一些类进行交互。客户和子系统的类进行直接的交互会导致client对象和子系统之间高度耦合。不论什么的类似于对子系统中类的接口的改动。会对依赖于它的全部的客户类造成影响。
从上面外观模式的定义我们看以看到外观模式能非常好的解决上述问题,为子系统提供了一个更高层次、更简单的接口,从而减少了子系统的复杂度和依赖。
这使得子系统更易于使用和管理。
外观是一个能为子系统和客户提供简单接口的类。当正确的应用外观。客户不再直接和子系统中的类交互,而是与外观交互。外观承担与子系统中类交互的责任。
实际上。外观是子系统与客户的接口。这样外观模式减少了子系统和客户的耦合度。
实例:
以下用一个简单的样例来说明外观模式:
结构图:
子系统类一般是一些业务类。实现了一些详细的、独立的业务功能,其典型代码例如以下:
class One{ public void MethodA(){ System.out.println( "methodA--> is runing" ); } } class Two{ public void MethodB(){ System.out.println( "methodB--> is runing" ); } } class Three{ public void MethodC(){ System.out.println( "methodC--> is runing" ); } } class Four{ public void MethodD(){ System.out.println( "methodD--> is runing" ); } }
在引入外观类之后,与子系统业务类之间的交互统一由外观类来完毕,在外观类中通常存在例如以下代码:
class Facade{ private One obj1 = new One(); private Two obj2 = new Two(); private Three obj3 = new Three(); private Four obj4 = new Four(); public void Method1(){ System.out.println("方法组1"); obj1.MethodA(); obj2.MethodB(); obj3.MethodC(); } public void Method2(){ System.out.println("方法组2"); obj1.MethodA(); obj2.MethodB(); obj4.MethodD(); } }
因为在外观类中维持了对子系统对象的引用,client能够通过外观类来间接调用子系统对象的业务方法,而无须与子系统对象直接交互。引入外观类后,client代码变得很easy。典型代码例如以下:
class Program{ static void Main(string[] args){ Facade facade = new Facade(); facade.Method1(); facade.Method2(); } }
何时使用外观模式?
第一:设计初期阶段,有意识的将不同的两个层分离,层与层之间建立外观Facade。这样就能够为复杂的子系统提供一个简单的接口,耦合性减少。
第二:在开发阶段,子系统往往由于不断的重构演化而变的越来越复杂,添加外观Facade能够提供一个简单的接口,降低它们之间的依赖性.
第三:维护一个大型系统时,可能这个系统已经很难以维护和扩展。此时能够为系统新开发一个Facade类,来提供设计粗糙或高度复杂的遗留代码的比較清晰简单接口。让新系统与Facade对象交互。Facade与遗留代码交互全部复杂的工作。
标签:alt art ring out src 耦合度 高度 简化 责任
原文地址:http://www.cnblogs.com/mfmdaoyou/p/6788959.html