对于重构的一点优化
功能入口，权限检测，反射，注册
适用于当业务复杂到一定程度之后，之后的每一步的添加和修改，都有可能和之前的业务逻辑进行交互和耦合的时候，传统的if 和 switch在状态变动的时候，修改过于频繁极其容易出现疏漏之处。
设定业务和权限的管理模型，可以分成三个部分，用户权限，业务权限，模块。
在模块的入口处，检测当前权限是否可以允许运行，而后检测业务模块判断。
检测的逻辑通过注册，在dll或者业务挂载或者初始化进去，设定前后运行的前后顺序，只在条件允许的情况下启动。
会稍微拖慢一下运行的启动逻辑，但是不会对业务中产生干扰。
复杂的业务逻辑体现在，业务的入口，中断，关闭，几个部分。
把最底层的模块抽象出，启动，关闭，切换三个部分。
比如调用硬件的业务，可以视为在业务权限检测后，检测硬件的使用权限，然后调用。
业务在关闭之后，关闭加载的硬件。
如果需要，切换的状态可以特殊定义，可以在硬件不关闭的情况下，改变参数。
假设业务无，现在执行业务1，需要调用abc三个子模块。先检测执行权限，复合后，检测判断当前状态，执行切换操作，比如业务在执行期间，根据优先级，判断是否可以强制关闭，如果业务想换，底层可以执行切换，业务不相关，则关闭上一步，然后执行新的。
比如切换硬件参数，在函数入口处，判断执行权限后，并不直接对硬件参数进行修改。
通过get和set方法，修改暂存变量，在暂存变量中，判断是否需要直接下发指令。
在默认业务中可以直接修改，在复杂业务时，则不需要，复杂业务中，因为修改上层变量，和物理硬件无关，所以改动内存即可，复杂业务在切换中调去内存参数即可。
这样设计代码框架比较好，但是代码写起来比较复杂，状态位的判定非常多，并且，继承结构并不是很好做。
权限判定可以通过数据库或者持久化的手段进行，这个逻辑中最简单的应用就是许可证。
权限认证不适合高频业务，最好只放在函数入口或者是对时间要求不敏感的区域中。
这样设计的业务结构，变动代码会少很多，可以通过预设的配置去修改权限。
不过会造成大量重复的代码，以及配置繁琐。