关于代码解耦

素颜马尾好姑娘i 2022-05-24 13:50 246阅读 0赞

烂的代码，都有各自烂的地方，不过基本都有一个共同的特点：耦合重，各个模块各个类各个功能点

之间关系牵扯不清，经常你调用我调用你，或者全局变量漫天飞；

对于怎么理清这些模块或者类，《代码大全》讲了很多，比如要形成金字塔型的调用层级关系，如果

不能保证，也一定要保证单向的调用关系，绝对不能形成环状的调用关系；

即：A->B->C

而不能是 A->B->C->A，尤其要避免 A<->B

如果不能避免这种循环调用，A和B将无法区分开来，A和B不可避免的扯到了一起，不能单独开发，不

能单独编译，无论改动A或者B中的一个，都会影响到另外一个；这样，随着功能一多，模块一多，最后全

扯到了一起；造成了你中有我，我中有你的感概恶心的耦合！！

如果能保证这种单调单向的调用关系，那代码将形成一定的上下有别的层级，其中任何一层只能调用

下层，绝对不能调用上层，最好是完全不用知道有上层！！即每层都把自己当作是最上层；

这样有几个好处：

1，模块解耦了，如果每层接口设计的好，那每层内部的改动对其他层或者其他模块完全是透明的，

这样有利于分工；

2，模块解耦之后，得到另外的一个好处是：能极大的增强代码模块的复用度，很多模块也许用着用

着就发现提取出来，可以供很多的上层模块调用；

对于集群中的svr节点来说，一般可以划分成一些固定的层：比如：核心数据模块，驱动模块，业务

模块，RPC模块，基础框架模块等等；

上面这些说的都是理论的玩意，而且很多人也都知道，但其实真正写代码的时候，往往发现事情没这

么简单，很多情况下，会发现A->B，B确实要反过来调用B；比如我经常发现有人这样写代码：

状态机FSM模块需要通过RPC模块拉取数据，得到数据后，然后才能接着往下继续处理；一般的 RPC

模块的接口是 rpc::get\_data(req, fsm\_id)，rpc得到数据后，根据fsm\_id从全局FSM管理器 g\_fsm\_mgr

取出FSM，然后调用 FSM::on\_data\_back(resp)...

看到没有，rpc 和 fsm 完整的融合在了一起，而且必须要通过全局变量融合(这里就会发生非常多的

恶心的地方，比如svr里面有两类都可能调用此rpc状态机...)，明显这里是有非常大的问题，rpc 明明和

业务是没半点关系的，rpc应该做的就是远程操作，至于操作的结果，rpc是不应该管的，他只需要简单的

把结果返回给调用者（即上层）即可；

按上面这种做法，rpc 是无法重用的，如果另外写一个svr，而这个svr用的同一套rpc，那他就只能

把这套rpc代码拷贝过来，然后再改几个地方...重复？恶心？低效？bug滋生？

其实对于这个问题，有极其简单极其有效却完全被人忽视的办法：回调！！

rpc提供的接口应该是这样的：

typedef (\*on\_data\_back)(resp,...)

rpc:get\_data(req, on\_data\_back cb, void\* params)

rpc只需要在内部建立这个req的标志（比如序列号）和 callback以及params的映射即可，当结果返回

时，只需要通过resp的标志找到回调信息，然后 cb(resp, params) 即可，至于cb到底是干什么的，rpc无

权知道，也不需要知道！！

对于所有的下层需要调用上层的情况，回调都应该是最好的选择，也是必须的选择；

C语言的精华是指针，指针的精华是函数指针，C的生命，C的灵动，C的多变来源于函数指针；君不见

稍微大点的纯C项目，函数指针都是极其常见的；

说起来其实很简单，确实够简单，却极致够用；那为什么很多项目中还是组织乱成一团麻呢？？

对于C++，回调没C这么简单，以前一直没有找到好用的自然的类函数指针的玩意，后来发现了boost的

function和bind这两个玩意，能完全实现类的回调，而且能随心所欲的携带参数，用多了感觉比C的函数指

针还好用，特别是携带参数这块；C完全依靠void\*这个指针携带，而boost的回调不限！！

https://blog.csdn.net/qwert9887/article/details/51741227

发表评论取消回复

表情：

评论列表（有 0 条评论，246人围观）

还没有评论，来说两句吧...

相关阅读

相关关于“解耦”的思考

当我们考虑解耦时，应当注意向自己提问题的方式，不应想着“怎样去解耦”（因为模块间肯定是存在联系的），而应想着“这一部分应当和哪一块耦合才能最大程度上降低耦合度”。以下是两个思考

青旅半醒/ 2024年02月19日 19:27/ 0 赞/ 68 阅读

相关什么是解耦

解耦的定义解耦（Decoupling）是指通过降低代码之间的依赖性，减少模块或组件之间的耦合程度。在软件开发中，解耦是一种良好的设计原则，它可以提高代码的可维护性、可测

- 日理万妓/ 2023年10月13日 13:26/ 0 赞/ 58 阅读

相关 ApplicationEvent实现业务解耦

这个还是2017年索道项目里面应用到技术，[hession通信][hession]，因为就我自己一个人开发，不想搞个rabbitmq之类的消息队列，来实现发布-订阅，解耦业务。

淩亂°似流年/ 2022年11月13日 14:27/ 0 赞/ 223 阅读

相关订单业务解耦

如何解耦（按照什么标准解耦）？ eg: 有一支付成功的订单，已经发货，用户取消订单？这个场景从业务设计上讲如何解耦？可能涉及的业务：订单业务、物流业务、支付业务(暂时只

我就是我/ 2022年09月05日 01:55/ 0 赞/ 247 阅读

相关软件解耦

现在在学习AngularJS，其中讲到了逻辑解耦能够大大的提高代码的可调性。不明白解耦是什么东西，于是百度了一下。说起软件的解耦必然需要谈论耦合度，降低耦合度即可以理解为解

电玩女神/ 2022年08月07日 05:58/ 0 赞/ 214 阅读

相关关于代码解耦

烂的代码，都有各自烂的地方，不过基本都有一个共同的特点：耦合重，各个模块各个类各个功能点之间关系牵扯不清，经常你调用我调用你，或者全局变量漫天飞；对于怎么理清这些模块或

素颜马尾好姑娘i/ 2022年05月24日 13:50/ 0 赞/ 247 阅读

相关关于Unity中的高度解耦和

主要是利用委托及事件的监听和广播来达到代码的高度解耦和以Button的点击事件为例进行简单的探讨：代码很简单只有短短的几十行代码（先上代码然后根据代码来简单说明）完

素颜马尾好姑娘i/ 2022年03月21日 18:57/ 0 赞/ 225 阅读

相关通过工厂解耦

代码目录结构 ![Snipaste\_2019-06-30\_19-54-53.jpg][Snipaste_2019-06-30_19-54-53.jpg] dao层

女爷i/ 2021年12月19日 19:13/ 0 赞/ 315 阅读

相关 Maven解耦和MVC

重要的写前面： 1 新建web层要新建 war 包的方式，不然无法新建servlet类。其他打成jar 包就行了。 2 下面的配置配置的是MAVEN

男娘i/ 2021年11月22日 10:54/ 0 赞/ 320 阅读

相关通过工厂实现解耦

代码目录结构 ![Snipaste\_2019-06-30\_19-54-53.jpg][Snipaste_2019-06-30_19-54-53.jpg] dao层

野性酷女/ 2021年10月30日 08:10/ 0 赞/ 369 阅读