换个角度理解设计模式之中间件思想-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();

是不是瞬间就变样了？ 最后的代码更接近实际业务一些，也就更利于后人维护代码时理解业务逻辑。

如果你的代码收拾整理后，可以达成“代码即业务，无逻辑调用和传参”的效果，就达到第一个阶段了。

总结

优点：只需要梳理下业务、修改下代码写法即可实现
缺点：只适用基础数据结构不变、使用多变、无序、无分支的场景

可以看到这种方式适用面还比较窄，我会在后面的文章中逐步分享适用面更广、更灵活的方式。