专业的网站制作正规公司,什么专业就业前景好,wordpress 调用页面,wordpress 幻灯片设置搞业务开发的时候#xff0c;发现有一些代码的开发会让人感觉非常简便舒服#xff0c;有一些代码的开发却有时候会让人感觉心智负担比较大。逐步总结的过程中#xff0c;发现让开发人员写起来感觉舒服的代码#xff0c;大概率是因为当前模块与其他模块代码耦合度低#xf… 搞业务开发的时候发现有一些代码的开发会让人感觉非常简便舒服有一些代码的开发却有时候会让人感觉心智负担比较大。逐步总结的过程中发现让开发人员写起来感觉舒服的代码大概率是因为当前模块与其他模块代码耦合度低开发人员无需花费过多的精力去关注其他模块的实现只需要专注于当前自己的功能实现即可。而通过实地对多个项目代码设计的对比发现都有一个非常通用的设计模式后面再通过阅读一些经验分享文章中发现大部分后台项目也都运用这个模式充分实现了模块之间的解耦极大提高了开发人员的幸福感这个通用的设计模式便是发布订阅模式游戏后台通常也叫事件监听模式 or 事件分发模式。一、什么是发布订阅事件监听设计模式发布订阅模式是一个简单通用的模式一般来说会专门实现一个类如LogicEventDispatch的类来负责维护发布者与订阅者之间关系也就是下图红框的位置。发布者有事件需要抛出时只需要把事件传给LogicEventDispatch再由LogicEventDispatch去调用各个订阅者的OnEventUpdate函数。以此来完成一次事件的发布与通知的整个流程。此处参考观察者模式与订阅发布模式的区别 - 一像素 - 博客园发布订阅模式上面这种实现只是一种通用实现之一。为何发布订阅模式可以充分解耦模块之间的耦合呢因为各个模块只需要关注自己需要的事件不需要关注各个模块具体实现是什么开发者只需要知道只要有事件抛出他就处理其他事情与现有功能开发无关因此各个模块实现更加内聚责任更加清晰由各个模块负责人各自保证自己的代码质量尽量减少多人同时修改同一个模块的行为。二、为何需要发布订阅事件监听设计模式发布订阅事件监听设计模式其最大功能便是实现模块之间的解耦。解耦的意义大家的都知道好但是好在哪呢这就要从项目研发状况说起游戏需求变更快开发量大特别是在项目临近测试节点时策划同学经常性会有临时新增需求临近测试基本各个模块功能测试同学都会逐一验证会经常性发现有功能遗漏这种需求一般排期都是比较紧张开发人员很难同时兼顾开发效率与开发质量。为了开发效率开发人员通常来说很难去完全通读原有设计所以就会出现各式各样的if判断语句而这种类型的代码也是最容易引发bug的地方之一。究其根源原因有两个2.1 耦合重度的模块之间存在网状依赖。大量的网状依赖导致开发人员想新增代码的时候基本上都需要走读一遍整个调用代码后才敢新增代码而且也很难新增代码耗费时间长容易有bug。举个例子图2.1网状依赖示例图为了更有代入感我们假设每个类的定位跟将游戏后台里面的类代入一下网状依赖中会有部分代码出现环状链路依赖我们通过一个更具体的例子来展现图2.2 环状链路依赖示例图我们假设有这样的代码ClassA::Func1接口调用 ClassB::Func1接口 ClassB::Func1接口调用 ClassC::Func1接口 ClassCFunc1 接口调用 ClassA::Func2接口但是ClassA::Func2接口又调用了ClassA::Func1接口这里形成了环状调用为什么没有造成递归是因为ClassA::Func1里面写了if语句去阻止递归。我们可以想象一下如果开发人员需要给ClassA::Func1新增功能代码其心智压力之大可见一斑。可能有人会说这种代码怎么可能会存在但是实际情况是这种代码还是会存在的。只不过在项目节奏放缓时或者出现问题时会被有心的同学重构掉。但是如果一个开发人员排期很紧那么他的开发压力就很大了因为重构需要测试保证开发人员没有太多的时间去做这么多的开发那么这就意味新的临时代码又将会再次增加即Class::Func1的if语句将会再次大概率增加。从去除网状依赖的角度出发我们需要解耦需要从框架去考虑尽可能解耦各个模块。1.2 老模块功能已经不完全符合现有需求老模块负责人不愿意改动其代码新功能代码必须僵硬适配老模块接口引发项目内新增大量临时适配代码。两个模块相互耦合在业务团队内归属两个不同的开发人员负责。举个例子开发人员A负责角色模块开发人员B负责角色伙伴模块。由于项目需求的更迭角色伙伴模块除了角色模块初始化时不满足现有功能外其他都还是满足现有需求的。这个时候开发人员A希望开发人员B可以按照现有需求修改一下角色伙伴功能模块的代码来解决初始化不符合规范的问题。但是开发人员B认为开发人员A可以通过写一些特殊适配接口来适配他的代码两人有可能无法互相说服。这最后的结果大概率就是开发人员A在角色伙伴模块写了很多if语句去解决初始化不规范的问题。这又再次导致了项目临时代码的增加。从这个角度出发我们也需要尽可能实现模块之间的解耦。三、如何设计发布订阅事件监听设计模式设计一个发布订阅事件监听设计模式一定要充分站在开发者使用的角度去设计这个事件模式开发人员用起来感觉简便清晰那么便是设计的成功。下面介绍一种设计思路关键在于事件参数传参的设计下面以C语言作为具体语言进行举例图3.1 统一事件参数设计// 触发事件模式如LogicRole 触发事件
class LogicRole {int HandleServiceA() {LogicEventDispatch::Instance().NotifyEvent(event_para);}
}// 事件分发调用
class LogicEventDispatch {int NotifyEvent() {for(auto handler : handlerList) {// step1. 派生事件先入队// step2. 处理主事件handler-OnEventUpdate(event_para);// step3. 处理派生事件队列}}
}// 事件处理, 开发人员只需要关注register操作与OnEventUpdate两个函数然后便是自己的业务代码
class LogicRolePartner {int init() {LogicEventDispatch::Instance().RegisterEventHandler(event_a, this);LogicEventDispatch::Instance().RegisterEventHandler(event_b, this);}int OnEventUpdate(EventPara* event_para) {switch(event_para-type) {case event_a: {HandleEventA(event_para);break;}case event_b: {HandleEventB(event_para);break;}//...}}
}
四、发布订阅事件监听设计模式需要注意的问题1、需要防止事件递归。事件再次触发同类型的业务需求是存在的。举个例子为玩家添加一个道具会抛一个使用道具变化事件同时这个道具是一个服务器自动使用的道具那么当服务器底层将这个道具使用之后便会再次抛出道具变化事件。或者任务完成事件会触发另外一个任务完成事件。所以事件触发抛同类型事件是有业务需求的所以这里需要将派生事件全部先入队处理完主事件再处理派生事件然后限制派生事件队列长度当派生队列长度超过配置值时需要立即告警通过微信企业微信等办公协作工具通知以保证开发人员可以在测试环境发现问题并处理。2、事件执行模块是无序的。使用这个模式不可以假定事件的执行顺序举个例子某个事件会触发为玩家添加角色的功能这个时候技能模块与角色模块同时关注这个事件但是技能模块先接到这个事件但是玩家角色模块还未初始化角色数据这样会导致技能模块在处理事件的时候产生大量报错。通常来说这种情况出现比较少可以在业务设计上来规避这个问题。五、发布订阅事件监听设计模式不适用场景1、业务设计流程要求顺序执行功能。有顺序执行的需求一般都是各种初始化逻辑如角色初始化因为像属性的初始化需要依赖于技能所以这一块的逻辑代码需要按照顺序执行直接调用各个模块的代码去执行初始化。如依次初始化角色技能角色伙伴角色属性等等。2、事件处理不能包含异步流程。如果事件处理代码中包含异步流程如请求数据库这个事件的处理需要依赖玩家Player对象的。当处理事件过程请求数据库当前事务或者协程切出。这个时候玩家Player对象被销毁那么当数据库回包协程恢复时就会找不到Player对象导致一系列报错与带来数据不一致的风险。因为从目前项目看来跨机跨进程事件的需求还是比较弱所以框架层上的实现未考虑跨机事件的设计。但从需求上来看如战斗单局需要与带有Player对象的gamesvr交互或者gamesvr与一些活动服的交互通过跨机事件来实现需求便是一个非常好的选择。所以这个是后续设计需要考虑的问题。本文参考了一些内部文章不方便在此发出在此仅以衷心的感谢致敬引用的文章的作者。这里仅是一家之言其实还有很多地方没说到如这个设计模式的具体实现上其实还有很多方式包括跨机事件的设计上也是非常值得讨论的后续再继续完善。
