外观模式
Facade:为子系统中的一组接口提供一个一致的界面。此模式定义了一个高层接口，这个接口使得这一子系统更加easy使用。
外观模式结构图
外观模式的实例：
理財投资中为了降低风险。购买基金，从而基金公司利用集合来的钱投资股票，国债。房子产。
购买基金的类图
代码实现：
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();
}
}
}
client代码
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模式仅对子系统对象的接口进行抽象。从而使它们更easy使用。它并不定义新功能。子系统也不知道Facade的存在。
通常来讲，仅须要一个Facade对象。因此Facade对象通常属于Singleton模式。
3）Adapter模式：
适配器模式是将一个接口通过适配来间接转换为还有一个接口。
外观模式的话。其主要是提供一个整洁的一致的接口给client。
总结
1）依据“单一职责原则”，在软件中将一个系统划分为若干个子系统有利于减少整个系统的复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。而达到该目标的途径之中的一个就是引入一个外观对象，它为子系统的訪问提供了一个简单而单一的入口。2）外观模式也是“迪米特法则”的体现。通过引入一个新的外观类能够减少原有系统的复杂度，外观类充当了客户类与子系统类之间的“第三者”，同一时候减少客户类与子系统类的耦合度。
外观模式就是实现代码重构以便达到“迪米特法则”要求的一个强有力的武器。
3）外观模式要求一个子系统的外部与其内部的通信通过一个统一的外观对象进行，外观类将client与子系统的内部复杂性分隔开，使得client仅仅须要与外观对象打交道，而不须要与子系统内部的非常多对象打交道。
4）外观模式从非常大程度上提高了client使用的便捷性，使得client无须关心子系统的工作细节。通过外观角色就可以调用相关功能。5）不要试图通过外观类为子系统添加新行为 。不要通过继承一个外观类在子系统中添加新的行为，这样的做法是错误的。外观模式的用意是为子系统提供一个集中化和简化的沟通渠道，而不是向子系统添加新的行为，新的行为的添加应该通过改动原有子系统类或添加新的子系统类来实现。不能通过外观类来实现。
刚開始学习的人，有表述不准确的请纠正！