【设计模式】外观模式

最新推荐文章于 2024-08-18 14:10:51 发布

SuperSources

最新推荐文章于 2024-08-18 14:10:51 发布

阅读量129

点赞数

分类专栏：设计模式

本文链接：https://blog.csdn.net/qq_45654306/article/details/108114795

版权

设计模式专栏收录该内容

26 篇文章 2 订阅

订阅专栏

外观（Facade）模式（门面模式）

本质：封装交互、简化调用

外部与一个子系统的通信必须通过一个统一的外观(Facade)对象进行，这就是外观模式。
外观模式要求一个子系统的外部与其内部的通信必须通过一个统一的外观(Facade)对象进行。外观模式提供一个高层次的接口，使得子系统更易于使用。
就如同医院的接待员一样，外观模式的外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道。
符合迪米特法则（Law of Demeter或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP）
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。最少知识原则告诉我们要减少对象之间的交互，只留下几个“密友”。

在这里插入图片描述
外观(Facade)角色：
客户端可以调用这个角色的方法。此角色知晓相关的(一个或者多个)子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。
子系统(subsystem)角色：
可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。

实例——基金与股票

class Stock1
{
//卖股票
    public void Sell()
    {
        Console.WriteLine(" 股票1卖出");
    }
//买股票
    public void Buy()
    {
        Console.WriteLine(" 股票1买入");
    }
}

//股票2
class Stock2
{
    //代码类似Stock1
}
class Stock3
{
    //代码类似Stock1
}
class NationalDebt1
{
    //代码类似Stock1
}
class Realty1
{
    //代码类似Stock1
}

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();
    }
}

class Program
{
    static void Main(string[] args)
    {
        Fund jijin = new Fund();
        jijin.BuyFund();
        jijin.SellFund();
        Console.Read();
    }
}

【GOF】的书中指出：在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。当然这并不意味着在整个系统里只能有一个外观类，而仅仅是说对每一个子系统只有一个外观类。或者说，如果一个系统有好几个子系统的话，每一个子系统有一个外观类，整个系统可以有数个外观类

何时使用？

当客户程序与抽象类的实现部分之间存在着很大的依赖性时，引入Facade将这个子系统与客户以及其他的子系统分离，为一个复杂子系统提供一个简单接口，Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。可以提高子系统的独立性和可移植性。
在层次化结构中，可以使用Facade模式定义系统中每一层的入口点，如果子系统之间是相互依赖的，则可以让他们仅通过Facade进行通信，从而简化他们之间的依赖关系。
希望包装或隐藏原有系统：Facade可以把原有系统作为自己的私有成员。原有系统与Facade类联系在一起，但使用Facade类的客户无法看到原有的系统。
维护一个遗留的大型系统或跟踪对系统的使用—强迫所有客户通过Facade使用原有系统。