概述
在软件开发系统中,客户程序会与很复杂系统的内部子系统之间产生耦合,而导致客户程序随着子系统的变化而变化,那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?这就需要我们的外观模式再好不过了。
目的
为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
结构图
对应源码
class Program
{
static void Main(string[] args)
{
Facade facade = new Facade();
//由于Facade的作用,客户端可以根本不知三个子系统类的存在,
facade.MethodA();
facade.MethodB();
Console.Read();
}
}
//四个子系统的类
class SubSystemOne
{
public void MethodOne()
{
Console.WriteLine(" 子系统方法一");
}
}
class SubSystemTwo
{
public void MethodTwo()
{
Console.WriteLine(" 子系统方法二");
}
}
class SubSystemThree
{
public void MethodThree()
{
Console.WriteLine(" 子系统方法三");
}
}
class SubSystemFour
{
public void MethodFour()
{
Console.WriteLine(" 子系统方法四");
}
}
//外观类
class Facade
{
SubSystemOne one;
SubSystemTwo two;
SubSystemThree three;
SubSystemFour four;
//外观类,它需要了解所有的子系统的方法或属性镜像组合,已被外界调用
public Facade()
{
one = new SubSystemOne();
two = new SubSystemTwo();
three = new SubSystemThree();
four = new SubSystemFour();
}
public void MethodA()
{
Console.WriteLine("\n方法组A() ---- ");
one.MethodOne();
two.MethodTwo();
four.MethodFour();
}
public void MethodB()
{
Console.WriteLine("\n方法组B() ---- ");
two.MethodTwo();
three.MethodThree();
}
}
运行结果
使用外观模式时机
(1):在设计初期阶段,应该要有意识的将不同的两个层分离,例如:三层结构,需要在数据访问层、业务逻辑层、表示层的层层之间建立外观模式,可以是复杂的子系统提供一个简单的接口,使得耦合度大大降低
(2):在开发阶段,子系统由于不断的重构演化而变得越来越复杂,增加外观模式可以提供一个简单的接口,减少它们之间的依赖
(3):在维护一个遗留的大型系统时,可能这个系统已经很难以维护和扩展了,但是它有很重要的功能,新的需求依赖它,使用外观模式也是非常合适的。
(4):外观模式,它不限制它们使用子系统类,可以再系统易用性和通用性之间选择。
(5):Facade模式对客户屏蔽了子系统组件,减少了客户处理的对象的数目使得子系统使用起来更加方便。
生活实例
现在来说快递行业很是火,我们很多人想由物件到制定的地方,我们要到快递机构填写我们要去的地址,之后,快递公司会根据我们不同的邮寄地址而准确的分开,此时快递的前台机构就是扮演着这个“外观”,他负责协调客户的订单、发送地点等工作他起到了一个接口的工作。
经典实例(投资基金)
class Program
{
static void Main(string[] args)
{
Fund jijin = new Fund();
jijin.BuyFund();
jijin.SellFund();
Console.Read();
}
}
class Fund
{
Stock1 gu1;
Stock2 gu2;
Stock3 gu3;
NationalDebt1 nd1;
Realty1 rt1;
//基金类,外观模式点,进行组合,已被外界调用
public Fund()
{
gu1 = new Stock1();
gu2 = new Stock2();
gu3 = new Stock3();
nd1 = new NationalDebt1();
rt1 = new Realty1();
}
public void BuyFund()
{
gu1.Buy();
gu2.Buy();
gu3.Buy();
nd1.Buy();
rt1.Buy();
}
public void SellFund()
{
gu1.Sell();
gu2.Sell();
gu3.Sell();
nd1.Sell();
rt1.Sell();
}
}
//股票1
class Stock1
{
//卖股票
public void Sell()
{
Console.WriteLine(" 股票1卖出");
}
//买股票
public void Buy()
{
Console.WriteLine(" 股票1买入");
}
}
//股票2
class Stock2
{
//卖股票
public void Sell()
{
Console.WriteLine(" 股票2卖出");
}
//买股票
public void Buy()
{
Console.WriteLine(" 股票2买入");
}
}
//股票3
class Stock3
{
//卖股票
public void Sell()
{
Console.WriteLine(" 股票3卖出");
}
//买股票
public void Buy()
{
Console.WriteLine(" 股票3买入");
}
}
//国债1
class NationalDebt1
{
//卖国债
public void Sell()
{
Console.WriteLine(" 国债1卖出");
}
//买国债
public void Buy()
{
Console.WriteLine(" 国债1买入");
}
}
//房地产1
class Realty1
{
//卖房地产
public void Sell()
{
Console.WriteLine(" 房产1卖出");
}
//买房地产
public void Buy()
{
Console.WriteLine(" 房产1买入");
}
}
运行结果
总结
外观模式作为结构型模式中的一个简单又实用的模式,外观模式通过封装细节来提供大粒度的调用,直接的好处就是,封装细节,提供了应用写程序的可维护性和易用性。外观模式一般应用在系统架构的服务层中,当我们是多个不同类型的客户端应用程序时,比如一个系统既可以在通过Web的形式访问,也可以通过客户端应用程序的形式时,可能通过外观模式来提供远程服务,让应用程序进行远程调用,这样通过外观形式提供服务,那么不管是什么样的客户端都访问一致的外观服务,那么以后就算是我们的应用服务发生变化,那么我们不需要修改没一个客户端应用的调用,只需要修改相应的外观应用即可,从某种程度上也达到了一种“解耦”的效果.
Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facdae很多时候更是一种架构
设计模式。
重要的区分:Facade模式、Adapter模式、Bridge模式与Decorator模式。Facade模式注重简化接口,Adapter模式注重转换接口,Bridge模式注重分离接口(抽象)与其实现,Decorator模式注重稳定接口的前提下为对象扩展功能。