Structural design issues, experts please come in

爱德华德

tobarstear

Haha, if you say that, I have nothing to say. It seems that I haven't passed the level you passed. I have gone to study.

sky_hexia

to:barstear

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

The picture you drew is what I think, I just borrowed from the organizational structure in the hardware system. In a hardware system, the CPU (equivalent to CWhat here) does not directly operate the peripherals, but through This is done by the hardware controller connected to the peripheral. For example, the CPU does not directly control the rotation of the hard disk (equivalent to a Device here) motor, and does not control the movement of the magnetic head. These are done with a hard disk controller (equivalent to DevXCtrler in the figure). ) Is done, what the CPU does is just write the correct control word or read the status word from the port (equivalent to the interface here) "exposed" by the controller of a different device, so to this extent, " The concept of "port" further reduces the coupling of CPU and hardware controller.

So you say that CWhat and DevXCtrler are tightly coupled, which is correct, because it is like the CPU in order to control the floppy disk, it must have a dedicated floppy disk instruction set, in order to control the hard disk, there must be a dedicated hard disk instruction set, but in fact the CPU does not have these. Instruction set is impossible. So in order to reduce the coupling of CWhat and DevXCtrler, the concept of ports can be simulated again, such as IPort.

This does cause code expansion, but the design pattern seems to be like this.If a certain code expansion can achieve high cohesion, low coupling, easy maintenance and expansion of each unit module, then this expansion is worth it.

This is just my humble opinion

72次灌水被抓

I don’t understand too much, sweat~~

If you are simply dealing with OS and device, then you can't create a prototype based on the interaction between OS and Device. For example, the message driver of Windows, the interrupt mechanism under DOS, the interface pointer, and there are piles of them in the registry. Device objects don’t need to be inherited from an Object. It’s too tiring, and compatibility issues are involved. It’s okay if they are all their own. There is no difference between a device and multiple devices. CWhat is responsible for interactive processing. Not interfere

lrvine

This seems not as complicated as LZ thought. I have written a similar processing program. In my program, I use a main thread to implement the CWhat mentioned by the host, and then define a global structure. This structure is mainly used to describe which device has occurred which event, when a device When an event occurs, the device automatically fills in the structure, and then triggers a signal, and the main thread is always in WAIT. When the signal is captured by the main thread, the main thread is processed through the device's pre-defined processing mode (the processing mode can be expanded, as long as there is a unified entry when writing the device object), in fact, the main thread is more to complete the task Scheduling work, and management of shared resources. Each device should be a completely independent part, interacting with each other through the scheduling of the main thread.

lrvine

To add, when writing the processing method, the host can pass the entry address of a function in the global structure, so that the main thread can process resources according to the requirements of each device when capturing, but the best shared resources Leave it to the main thread for unified management, otherwise you need to introduce a lot of management strategies!

barstear

to:sky_hexia
Haha, I'm thinking about making appropriate changes.The interface between device and CWhat is combined with DevXCtrler.Complex devices are handled by DevXCtroler, and simple interfaces are used.

to:lrvine
Haha, a very good idea. There are a few questions: Is the address of the member function of the stored class in the global structure? The CWhat callback Device can be implemented to get its status, right?
Haha, unfortunately, there are many functions to call back, and the parameter list is also different. This is back to the problem of "unable to define a unified interface". It is a good idea to send a signal to the device, but if CWhat does not have time to process, and It sent a second signal. The front and back states of this device are covered. If you use a container to store each state, alas, it will cost a lot of overhead. System kernel-level signal switching is also very resource intensive. . CWhat actively calls Device, which is not easy to implement.
Haha, but when I first saw it, I was really excited.

sky_hexia

tobarstear

My idea is indeed too complicated and impractical. I didn't see that you need to be more concise, enough to use the requirements, you may go on the road of no return, please consider other people's ideas.

chenb7

It's a little complicated. Don't over design.

barstear

to:chenb7
Simple problems should be handled simply. Complex problems should also be handled simply, but simplicity is always relative.

The design is basically done, and the code will be posted when you have time.

xiatianxws

Actually I compare the same view

onestation (newbie)

If you don't want to define too many interfaces, you can define it like this:
struct IDeviceEvent
{
virtual long OnEvent1(int nEventId, void* pSender, void* pParam){};
};
CWhat only inherits IDeviceEvent, and then judges by conditions such as nEventId.





Haha, the abstraction is too much and the workload is too much. Don’t get through with yourself. If you look at the implementation of Office plug-ins, there should be a lot of gains.