外观模式
Facade:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
外观模式结构图
外观模式的实例:
理财投资中为了减少风险,购买基金,从而基金公司利用集合来的钱投资股票,国债,房子产。
购买基金的类图
代码实现:
namespace 外观模式_炒股
{
//股票1
class Stock1
{
//卖出股票
public void Sell()
{
Console .WriteLine ("股票1卖出");
}
//买股票
public void Buy()
{
Console .WriteLine ("股票1买入");
}
}
class Stock2
{
//卖出股票
public void Sell()
{
Console.WriteLine("股票2卖出");
}
public void Buy()
{
Console.WriteLine("股票2买入");
}
}
class Stock3
{
//卖出股票
public void Sell()
{
Console.WriteLine("股票3卖出");
}
public void Buy()
{
Console.WriteLine("股票3买入");
}
}
class NationDebt1
{
//卖出国债
public void Sell()
{
Console.WriteLine("卖出国债");
}
public void Buy()
{
Console .WriteLine ("买入国债");
}
}
class Realty1
{
public void Sell()
{
Console .WriteLine ("卖房");
}
public void Buy()
{
Console .WriteLine ("卖房");
}
}
class Fund
{
Stock1 gu1;
Stock2 gu2;
Stock3 gu3;
NationDebt1 nd1;
Realty1 rt1;
public Fund()
{
gu1 = new Stock1();
gu2=new Stock2 ();
gu3 = new Stock3();
nd1 = new NationDebt1();
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();
}
}
}
客户端代码
static void Main(string[] args)
{
Fund jijin = new Fund();
//基金购买
jijin.BuyFund();
//基金赎回
jijin.SellFund();
Console.Read();
}
外观模式适用情景
分三个阶段,首先,在设计初期阶段,应该有意识的将不同的两个层分离,层与层之间建立外观Facade,这样可以为复杂的子系统提供一个简单的接口,使得耦合大大降低。其次,在开发阶段,子系统往往因为不断的重构演化而变的越来越复杂,增加外观facade可以提供一个简单的接口,减少它们之间的依赖。第三,在维护一个一流的大系统时,可能这个系统已经非常难以维护和扩展了,可以为新系统开发一个外观facade类,来提供设计粗糙或高度遗留代码的比较清晰简单的接口,让新系统与facade对象交互,facade与遗留代码交互所有复杂的工作。
外观模式与其他模式
以下作为扩展学习内容
摘自:http://blog.csdn.net/hguisu/article/details/7533759
1)抽象工厂模式:Abstract Factory式可以与Facade模式一起使用以提供一个接口,这一接口可用来以一种子系统独立的方式创建子系统对象。 Abstract Factory也可以代替Facade模式隐藏那些与平台相关的类。
2)中介模式:Mediator模式与Facade模式的相似之处是,它抽象了一些已有的类的功能。然而,Mediator的目的是对同事之间的任意通讯进行抽象,通常集中不属于任何单个对象的功能。
Mediator的同事对象知道中介者并与它通信,而不是直接与其他同类对象通信。相对而言,Facade模式仅对子系统对象的接口进行抽象,从而使它们更容易使用;它并不定义新功能,子系统也不知道Facade的存在。
通常来讲,仅需要一个Facade对象,因此Facade对象通常属于Singleton模式。
3)Adapter模式:
适配器模式是将一个接口通过适配来间接转换为另一个接口。
外观模式的话,其主要是提供一个整洁的一致的接口给客户端。
总结
1)根据 “单一职责原则”,在软件中将一个系统划分为若干个子系统有利于降低整个系统的复杂性,一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小,而达到该目标的途径之一就是引入一个外观对象,它为子系统的访问提供了一个简单而单一的入口。2)外观模式也是“迪米特法则”的体现,通过引入一个新的外观类可以降低原有系统的复杂度,外观类充当了客户类与子系统类之间的“第三者”,同时降低客户类与子系统类的耦合度。外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。
3) 外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行,外观类将客户端与子系统的内部复杂性分隔开,使得客户端只需要与外观对象打交道,而不需要与子系统内部的很多对象打交道。
4) 外观模式从很大程度上提高了客户端使用的便捷性,使得客户端无须关心子系统的工作细节,通过外观角色即可调用相关功能。5)不要试图通过外观类为子系统增加新行为 ,不要通过继承一个外观类在子系统中加入新的行为,这种做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道,而不是向子系统加入新的行为,新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现,不能通过外观类来实现。
初学者,有表述不准确的请纠正!