结构设计问题,高手请进

爱德华德

to barstear

呵呵，你要是这么说，我就无话可说了，看来你走过的那关我还没过呢，学习去了

sky_hexia

to:barstear

==========    =========    ========       ========
| CDevice1 |  | CDevice2|  |CDevice3| ... |CDeviceN|
==========    =========    ========       ========
      ↑           ↑          ↑            ↑
      ↓           ↓          ↓            ↓
  Dev1Ctrler Dev2Ctrler   ...            ...
      ↑           ↑          ↑            ↑
      ↓           ↓          ↓            ↓
=======================================================
|                CWhat ?                                     |
======================================================

你画的图就是我想的, 我不过是借鉴了硬件系统中的组织结构, 在一个硬件系统中, CPU(相当于你这里的CWhat), 并不会直接操作外设的工作, 而是通过与外设相连的硬件控制器来完成的, 例如CPU不会直接控制硬盘(相当你这里的一个Device)马达的旋转, 不会控制磁头的运动, 这些是用硬盘控制器(相当于图中DevXCtrler)完成的, CPU所做的只是象不同设备的控制器"暴露"出来的端口(相当于这里的接口)写入正确的控制字, 或从中读出状态字, 所以在这种程度上, "端口"的概念进一步降低了CPU和硬件控制器的偶合.

所以你说CWhat和DevXCtrler是紧偶合, 是对的, 因为这就好比CPU为了控制软盘, 要有专用软盘指令集, 为了控制硬盘又要有一套专用的硬盘指令集, 但实际上CPU并没有这些指令集, 也不可能有. 所以为了降低CWhat和DevXCtrler的偶合, 可以再模拟出端口的概念, 比如IPort.

这样确实会造成代码膨胀, 但设计模式好像就是这样的, 如果通过一定代码的膨胀可以实现各个单元模块的高内聚, 低偶合, 易于维护和扩展, 那这种膨胀还是值得的.

这只是我的拙见

72次灌水被抓

没太明白，汗~~

如果单纯的类似OS与device打交道，那就以OS与Device的交互为原型创建不就得了，比如Windows的消息驱动，DOS下的中断机制，接口指针么，注册表里存了一堆堆的，设备对象也不用从一个Object下继承出来，太累了，还涉及兼容性问题，如果都是自己的东西那倒也无妨，一个device跟多个device没什么区别，CWhat负责交互处理，Device之间互不干涉

lrvine

这个好象没LZ想的那么复杂吧。我写过类似的处理程序，在我的程序里，我把楼主说的CWhat用一个主线程来实现，然后定义一个全局的结构，这个结构主要用于描述哪个设备发生了哪个事件，当一个设备发生某个事件的时候，设备自动填充结构，然后触发一个信号，主线程一直在WAIT。当信号被主线程捕获的时候，主线程就通过设备预先定义的处理模式处理（处理模式可以外扩的，只要在写设备对象的时候有统一的入口），其实主线程更多的是完成任务调度工作，和共享资源的管理。每个设备应该是完全独立的部分，通过主线程的调度互相作用而已。

lrvine

补充一下，楼主在写处理方法的时候，可以通过在全局结构中传递一个函数的入口地址，这样主线程在捕获的时候就完全可以按照各个设备的要求去处理资源了，不过共享资源最好还是留给主线程统一管理，不然你需要引入很多管理策略！

barstear

to:sky_hexia
呵呵,我正在考虑适当的变通一下,device和CWhat间用 接口 和 DevXCtrler结合的方式, 复杂的设备用DevXCtroler处理,简单的就用接口.

to:lrvine
呵呵,很不错的想法,有几个疑问点: 全局结构里面的存类的成员函数地址吗? 那样来实现CWhat回调Device以获取它的状态,呵呵是这个意思吧?  
呵呵,遗憾的是,要回调很多个函数啊,而且参数列表也不同,这又回到"无法定义一个统一接口"问题上了.  设备发信号是个好的想法,但如果CWhat没来得及处理,而它又发了第二个信号,这个设备的前后两个状态有覆盖的情形,如果用容器存储每个状态的话,唉,要很大的开销啊.系统内核级的信号切换也很耗资源啊.  CWhat主动调用Device,也不好实现啊.  
呵呵,不过刚开始看的时候,确实有些心动.

sky_hexia

to barstear

我的想法确实太复杂不实际, 没看到前面你需要越简洁, 够用就好的要求,可能会走上不归路, 请考虑其他人的想法吧.

chenb7

搞得有些复杂了。不要过度设计。

barstear

to: chenb7
简单问题,要简单处理. 复杂问题也要努力简单处理,但简单始终是相对的.

设计基本出来了,有时间就把代码贴上来.

xiatianxws

实际上我比较同一这个的观点

onestation(新手)

如果不想定义太多接口可这样定义：
struct IDeviceEvent
{
virtual long OnEvent1(int nEventId, void* pSender, void* pParam){};
};
CWhat只用继承IDeviceEvent，再通过nEventId等条件判断。





呵呵，抽象过头了工作量太大，不要和自己过不去啊，你看看 Office 的插件实现方式，应该会有不少收获