設計模式之橋接

—阿輝發表於2021-08-21
設計模式橋接

橋接模式的介紹

橋接模式就是通過將抽象部分與實現部分分離，把多種可匹配的使用進行組合。其實就是在A類中含有B類介面，通過建構函式傳遞B類的實現，這個B類就是設計的橋。

它是一種結構型設計模式，可將一個大類或一系列緊密相關的類拆分為抽象和實現兩個獨立的層次結構，從而能在開發時分別使用。

其實簡單說就是將一個複雜類/物件進行拆分，拆分為介面(抽象)和實現，利用介面中的某一例項變數來呼叫實現的某一塊邏輯實現(這個過程最最重要的就是通過建構函式來宣告和傳遞)。

橋接模式的結構

1、抽象部分：提供高層控制邏輯，依賴於完成底層實際工作的實現物件。

2、實現部分：為所有具體宣告通用介面。抽象部分僅能通過在這裡宣告的方法與實現物件進行互動。

抽象部分可以列出和實現部分一樣的方法，但是抽象部分通常宣告一些複雜行為，這些行為依賴於多種由實現部分宣告的原語操作。

3、具體實現：實現部分的物件模組，繼承於實現部分。

4、精確抽象：提供控制邏輯的變體，與其父類一樣，它們通過實現介面與不同的實現進行互動。

一般情況下，客戶端只關心如何與抽象部分合作，但是客戶端需要將抽象物件與一個實現物件連線在一起。

  • 想拆分或重組一個具有多重功能的龐雜類
  • 希望在幾個獨立維度上擴充套件一個類
  • 需要在執行時切換不同實現方法

設計模式並不是一種對類進行組織的方式，它還能用於溝通意圖 和解決問題。

橋接模式的優缺點

優點：

  • 可建立與平臺無關的類和程式

  • 客戶端程式碼只與高層抽象部分互動，不會接觸到平臺的詳細資訊(具體的實現方式)

  • 滿足開閉原則。可以新增抽象部分和實現部分，且它們之間不會相互影響

  • 單一職責原則。抽象部分專注於處理高層邏輯，實現部分處理平臺細節。

缺點：

  • 別的高內聚的類中使用此模式，不然會越來越複雜。

橋接、狀態模式和策略模式的介面都非常相似。實際上，它們都基於組合模式 ：即將工作委派給其他物件，不過也各自解決了不同的問題。

層次結構中的第一層(抽象部分)將包含對第二層(實現部分)物件的引用。抽象部分能將一些對自己的呼叫委派給實現部分的物件。

所有的實現部分都有一個通用介面，因此它們能在抽象部分內部相互替換。

Demo

    /// <summary>
    /// 支付類  （抽象部分）
    /// </summary>
    public class Pay
    {
        protected IPayMode _padMode;                    

        public Pay(IPayMode padMode)
        {
            this._padMode = padMode;
        }

        public virtual string Validation(int uId,string uName) 
        {
            return "驗證情況彙報："+_padMode.IsControl(uId);
        }
    }

具體的實現

    /// <summary>
    /// 支付寶支付  (具體實現類)
    /// </summary>
    class zfbPay:Pay
    {
        public zfbPay(IPayMode _padMode)
            : base(_padMode)
        { 

        }

        public override string Validation(int uId, string uName)
        {
            var isValue =_padMode.IsControl(uId);
            return "支付寶正在進行驗證操作 ，" + isValue + "，使用者：" + uName;
        }
    }

    /// <summary>
    /// 微信支付  (具體實現類)
    /// </summary>
    class wxPay:Pay
    {
        public wxPay(IPayMode padMode) :base(padMode){

        }        

        public override string Validation(int uId, string uName)
        {
            var isValue = _padMode.IsControl(uId);
            return "微信正在進行驗證操作：" + isValue+"，使用者："+uName;
        }
    }

介面部分

   /// <summary>
    /// 支付模式 
    /// 人臉識別、密碼識別
    /// </summary>
    public interface IPayMode
    {
        /// <summary>
        /// 是否滿足風控要求
        /// </summary>
        /// <param name="uId"></param>
        /// <returns></returns>
        string IsControl(int uId); 
    }

    /// <summary>
    /// 人臉識別
    /// </summary>
    public class FaceRecognition : IPayMode
    {
        public string IsControl(int uId)
        {            
            return "人臉識別成功，你的ID為 " + uId + "滿足風控要求，支付成功。";
        }
    }

    /// <summary>
    /// 賬號密碼
    /// </summary>
    public class PasswardInput:IPayMode
    {
        public string IsControl(int uId)
        {            
            return "密碼識別成功，你的ID為 " + uId + "滿足風控要求，支付成功。";
        }
    }

測試驗證

    class Program
    {
        static void Main(string[] args)
        {
            Pay wxPay = new wxPay(new FaceRecognition());
            var result=wxPay.Validation(001,"阿輝");
            Console.WriteLine(result);

            Pay zfbPay = new zfbPay(new PasswardInput());
            result=zfbPay.Validation(002,"阿七");
            Console.WriteLine(result);
            Console.ReadKey();
        }
    }

不關心具體實現，只是單純的呼叫。

仔細看上面的程式碼，在測試驗證部分，我們只是需要使用哪一種付款模式就直接傳遞值進去就可以，不需要關係具體內部的實現邏輯，也滿足單一職責原則和開閉原則。

小寄語

人生短暫，我不想去追求自己看不見的，我只想抓住我能看的見的。

我是阿輝，感謝您的閱讀，如果對你有幫助，麻煩點贊、轉發 謝謝。

相關文章