读一个旧程序，是一个特殊协议的客户端，分两个class

class Conection
提供了发送某些消息给服务器的方法
init_conn()
sendXXCmd()
sendYYCmd()
还有收到服务器发来的消息之后做初步解析，然后调用不同方法的dispatcher
但这个dispatcher调用的处理函数并不在这个class里，也不在其派生类里
而是在另一个class里

class Client
onRecvXX()
onRecvYY()
但它不管具体的通信，收到就已经是解码好的消息了


其实有点像SocketServer和Handler的关系，但那个是服务器；这是什么套路或者模式？

写客户端，我自己可能会合并成一个class
--
FROM 222.71.112.*

这模式挺常见啊。
期货程序化交易里最常用的CTP就是这样设计的，一个client类来处理通信，还有一个SP类里定义了一堆OnXXX来处理消息。

要说有这样设计有什么好处的话，一是方便团队合作，两个类的开发人员是不同的。二是可以支持一个通信类关联多个消息处理对象。

【 在 JulyClyde 的大作中提到: 】
: 读一个旧程序，是一个特殊协议的客户端，分两个class
: class Conection
: 提供了发送某些消息给服务器的方法
: ...................
--
FROM 58.33.81.*

【 在 RunningOn 的大作中提到: 】
: 要说有这样设计有什么好处的话，一是方便团队合作，两个类的开发人员是不同的。二是可以支持一个通信类关联多个消息处理对象。
那其实也可以让class client继承自class connection啊
class connection只需要调“自己的”onXX方法就可以了
具体功能在派生类里实现

为什么我见到的这个，还有标准库的socketserver都选择用两个独立class做组合呢？
--
FROM 222.71.112.*

倒是……
1 确实我不怎么做测试
2 跟随你的思路理解一下，确实拆开之后比较方便。client类可以和mock connection合
作做测试了。如果说client继承自connnection那就必须mock通信对方了，还只能一次测
试俩class
【 在 thisyears 的大作中提到: 】
: 如果你平时不做单元测试，只做集成测试，什么模式对你来说都差不多。
: 如果你做单元测试，你会发现分成两个部分实现，比较好做单元测试。
: 我发现，设计模式里面说的各种解耦，一个类不要有太多的职责等等。如果你期望后续
: 有不确定需求变更，正好可以应用上你的设计，经常会和过度设计纠缠不清。但如果你多
: 做单元测试，你就会发现好处立马体现出来了。
--
FROM 222.71.112.*

很多客户端都这么写，前者负责跟网络交互，后者有具体的业务逻辑（或者提供给人注入业务逻辑的接口），这样才方便业务隔离

【 在 JulyClyde 的大作中提到: 】
: 读一个旧程序，是一个特殊协议的客户端，分两个class
: class Conection
: 提供了发送某些消息给服务器的方法
: ...................
--
FROM 103.107.216.232