換個角度理解設計模式之中間件思想-1-鏈式

系列文章的目錄：https://blog.csdn.net/hjkl950217/article/details/89490709

記住：設計模式重理解，輕照搬

想解決的問題

大部分後端業務開發，要做的事相對單一，邏輯路線不復雜，在普遍的設計方法中主要是使用OOP(面向對象編程) 或 DDD(領域驅動)。 前者非常容易因爲項目上的原因退化成面向過程，而後者非常依賴所有技術人員的技術水平。

我想要總結出一套方法：讓設計過程不那麼困難，使用門檻低，同時又非常利於後期維護。

後來從.net core的web啓動方式中，它使用的中間件方式給我帶來的靈感

什麼是中間件思想

這個是我自己慢慢總結出一套方法，參考了鏈式編程思想、中間件思想和實際業務開發中慢慢摸索出的一套方法。達成的效果則是業務代碼執行過程、邏輯模型都是線性的，維護時影響是隔離的，新加需求只需要添加代碼即可。
定義：一種應用於業務編程的設計方法，產生邏輯線性、易維護的代碼。

而後端開發中遇到的性能問題、分佈式設計、並行開發等等，都不適用於這套方法哦。

適用場景

1. 大部分後端普通業務開發
2. 業務流程分支相對較少
3. 變化少的業務邏輯點

第3點爲了理解再說明一下：假如要做圖書管理系統項目，需求說需要用借書卡來借書還書。用DDD方法可以分析出一個點：管理系統需要一個驗證器用來在借書還書時做驗證使用。 借書卡只是用來驗證的一個東西，替換成人臉識別一樣可以達到驗證的目的，這種“驗證器”就是變化少的業務邏輯點。

中間件思想

開頭說一下：我會將我在不同階段使用的方法講訴出來。這些方便不代表屬於落後的方式，而是適用於不同的業務場景。靈活多變+邏輯呈線性我認爲纔是這套理論的核心，當你慢慢領悟了這種思想之後，也可以使用你自己的方式來實現。
我會將每種方式的特點單獨列出，並且會用簡單的示例代碼來表達我的實現過程。

階段1-鏈式

特點：原始數據固定不變，驗證邏輯可以無序

我在做一次權限驗證時第一次使用這種方法。做過權限的朋友應該都有體會權限邏輯的特點就是基礎結構和值比較固定，但是不同的業務場景下要求不同的驗證方式和權限值的組合驗證。

權限值：

    public enum RoleEnum
    {
    	NormalUser = 1,//普通用戶
        InternalUser = 2,//內部用戶
        Developer = 4,//開發者
    }

數據：

姓名	權限值
張三	3
李4	6

如果要判斷張三有沒有內部用戶的權限會怎麼做呢? 加一個位於就可以了

bool isRole=(張三.權限值|RoleEnum.NormalUser)==RoleEnum.NormalUser;//true

如果你要判斷的權限是普通用戶+內部用戶，又怎麼判斷呢？

bool isRole1=( 張三.權限值|RoleEnum.NormalUser )==RoleEnum.NormalUser;//true
bool isRole2=( 張三.權限值|RoleEnum.InternalUser )==RoleEnum.InternalUser;//true

bool result=isRole1 && isRole2;//true

而鏈式會這樣寫：

      //基礎方法 判斷不過則返回null
        private static RoleEnum? CheckRole(this RoleEnum sources, RoleEnum? target)
        {
            if (target == null) return null;
            bool isSeccess = (sources | target) == target;
            return (isSeccess == true) ? target : null;
        }
       //基礎方法，將枚舉值轉換爲true和false
        public static bool IsCheckSuccess(this RoleEnum? target)
        {
            return (target == null) ? false : true;
        }

使用的代碼：

bool isRole=張三.權限值
				.CheckRole(RoleEnum.NormalUser)
				.CheckRole(RoleEnum.InternalUser)
				.IsCheckSuccess();

CheckRole(RoleEnum.DevBoss)再封裝一下:

        public static RoleEnum? IsInternal(this RoleEnum? target)
        {
            return RoleEnum.InternalSeller.CheckRole(target);
        }

        public static RoleEnum? IsNormal(this RoleEnum? target)
        {
            return RoleEnum.NormalSeller.CheckRole(target);
        }

效果：

bool isRole=張三.權限值
				.IsNormal()
				.IsInternal()
				.IsCheckSuccess();

是不是瞬間就變樣了？ 最後的代碼更接近實際業務一些，也就更利於後人維護代碼時理解業務邏輯。

如果你的代碼收拾整理後，可以達成“代碼即業務，無邏輯調用和傳參”的效果，就達到第一個階段了。

總結

優點：只需要梳理下業務、修改下代碼寫法即可實現
缺點：只適用基礎數據結構不變、使用多變、無序、無分支的場景

可以看到這種方式適用面還比較窄，我會在後面的文章中逐步分享適用面更廣、更靈活的方式。