通信模型之“透明”

    今天是大牛走后的第一周,大牛走了,理所当然所有的代码变成我维护修改了。由于最开始写的是写一步算一步,现在0.0.1版release后发现代码结构有很多不合理,理所当然要重构。首先重构的当然是影响着整的前后台系统的socket通信。之前socket的设计是这样的:

     前后台系统共用一个socket.dll,使用socket.dll来封装socket的部分。但是今天看代码时发现其实bg(后台程序)与fg(前台程序)分别加载时socket时,socket.dll分别在两个进程中都有一分部没用的数据与代码拷贝,如后台只需要服务端的相关处理部分数据与代码,前台只需要客户端的处理部分与代码,放在一个DLL中逻辑上看起来很不优雅。而且在socket.dll的代码中定义了一套与外部接口相对应的内部通信数据结构,如socket.dll 导出一个s_aa(struct bb *p)样子的接口那么socket.dll中必有一个struct bb_private与之对应,在调用s_aa时其实p所指向的参数是会被转成struct bb_private后才会被发出去。个人感觉这样做,这个socket.dll仅仅是一个库,如果以后增加了一个功能,这个库可能就需要修改很大,不能实现高内聚低耦合的宗旨。

      个人认为优雅的实现应该是这样的:

    SocketClient.dll与SocketServer负责Socket通信的处理,但是这两个DLL并不知道所有Socket之上的东西,他们仅提供一种机制那就是“透明”,将前台(Client)与后台(Server)之间的网络透明掉,让程序的数据与处理在逻辑上如图中虚线那样执行,如FG调用BG的某个功能,Socketxx.DLL并不需要知道任何关于这个功能函数的数据结构,逻辑上看就像是前台直接调用了BG的函数然后得到了BG函数的返回值。这时Socketxx.DLL不需要知道任何调用的细节,这就是机制,如果要加一个FG调BG的功能函数,那么只需要修改FG与BG而不需要同时修改Socketxx.DLL这两个DLL,这才是透明机制。这样一看逻辑上就清晰多了,而且也优雅多了。



评论

  1. 高大上

  2. @logguo 胡写的哈,给点意见噻!

  3. […] 他走之后我来维护他那部分socket代码时总是很容易搞错, 于是把socket部分给重写了. 在实现socket命令处理之初我在把socket命令放在每一个模块的顶层去调用, […]

发表评论