設計模式之外觀模式

外觀模式(門面模式) Facade

Intro

外觀模式（Facade），為子系統中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用

Prototype

• Facade: 外觀類，知道哪些子系統類負責處理請求，將請求代理給對應的子系統對象
• SubSystem Classes，實現子系統中的功能，處理 Facade 指派的任務，和 Facade 沒有關聯關系，沒有繼承，也不會引用 Facade

public class SubSystem1
{
    public void MethodA()
    {
        Console.WriteLine("MethodA in SubSystem1");
    }

    public void MethodB()
    {
        Console.WriteLine("MethodB in SubSystem1");
    }
}
public class SubSystem2
{
    public void MethodA()
    {
        Console.WriteLine("MethodA in SubSystem2");
    }

    public void MethodB()
    {
        Console.WriteLine("MethodB in SubSystem2");
    }
}
public class SubSystem3
{
    public void MethodA()
    {
        Console.WriteLine("MethodA in SubSystem3");
    }

    public void MethodB()
    {
        Console.WriteLine("MethodB in SubSystem3");
    }
}

public class Facade
{
    private readonly SubSystem1 _subSystem1 = new SubSystem1();
    private readonly SubSystem2 _subSystem2 = new SubSystem2();
    private readonly SubSystem3 _subSystem3 = new SubSystem3();

    public void MethodA()
    {
        _subSystem1.MethodA();
        _subSystem2.MethodA();
        _subSystem3.MethodA();
        Console.WriteLine();
    }

    public void MethodB()
    {
        _subSystem1.MethodB();
        _subSystem2.MethodB();
        _subSystem3.MethodB();
        Console.WriteLine();
    }
}

var facade = new Facade();
facade.MethodA();
facade.MethodB();

應用場景

• 解決易用性問題，可以用來封裝系統的底層實現，隱藏系統的復雜性，提供一組更加簡單易用、更高層的接口。
• 解決性能問題，通過將多個接口調用替換為一個門面接口調用，減少網絡通信成本，提高 App 客戶端的響應速度。API 聚合就是屬於這種，也是屬於外觀模式的應用
• 解決事務問題，通過門面模式可以方便的使得原本多個操作可以在一個事務內完成，如果中間某一個環節操作失敗，可以回滾事務，撤銷變更

More

接口設計的好壞，直接影響到類、模塊、系統是否好用。所以，我們要多花點心思在接口設計上。

完成接口設計，就相當於完成了一半的開發任務。只要接口設計得好，那代碼就差不到哪里去。接口粒度設計得太大，太小都不好。太大會導致接口不可復用，太小會導致接口不易用。

在實際的開發中，接口的可復用性和易用性需要“微妙”的權衡。針對這個問題，我的一個基本的處理原則是，盡量保持接口的可復用性，但針對特殊情況，允許提供冗余的門面接口，來提供更易用的接口。

Reference

• https://github.com/WeihanLi/DesignPatterns/tree/master/StructurePattern/FacadePattern