Structural design issues, experts please come in

barstear

Simply put:
There are three classes, CDevice1, CDevice2, and CDevice3, each of which starts its own thread and runs in a blocking mode. There is a CPolling class, which needs to be called periodically to get its status and can give it commands.
The picture is as follows:

 =========== ===========================
| CDevice1 | | CDevice2 | | CDevice3 | | CPolling |
 =========== ===========================
      ↑ ↑ ↑ ↑
      ↓ ↓ ↓ ↓
======================================================= =====
| CWhat? |
| |
======================================================= =====
       ↑ |
       ↓ ↓
 =============================
| CSocketCmd | | CSaveModule |
 =============================

In the middle layer, I strongly named a CWhat module. How can this structure be designed?
The first thing to exclude is SendMassage (), because it inherits CWnd and requires too much swtich (). This has a large performance impact.
I thought about it like this:
Interface IDevice1 {..} IDevice2 {..} IDevice3 {..} ...
class CWhat: public IDevice1, public IDevice2, public IDevice3
{
void Dev1 ();
void Dev2 ();
void Dev3 ();
...
}

Called in CDevice:
void CDevice :: Regist (IDevice1 * pDev1)
{
  _pDev1 = pDev1;
  ...
}
void CDevice :: ThreadCallBack ()
{
  _pDev1-> IDevice1Funtion ();
}
// This implements the process that Device calls CWhat, and then defines the interface in this way, and then calls this way to implement the process that CWhat calls each Device.

// Note: Each Device has different functions, so you cannot draw a base class on them.

This was originally a good solution, but alas, there are many classes like CDevice, and CWhat should inherit
Too many interfaces.
Is there any good way for everyone? Welcome everyone to discuss.

liuhai731

CMutex, CSamphore, etc. will do

koby806

All CDevice1 inherit an interface IDevice, this interface has a common method DoSomething
Then maintain a list in CWhat vector<>, array can be

void CDevice::Regist(IDevice* pDev)
{
    m_vector.push_back(pDev);
}

void CDevice::ThreadCallBack()
{
    for (xxx)
    {
        IDevice* pDevice = vector[i];
        if (pDevice != NULL)
             pDevice->DoSimething();
    }
}

sky_hexia

Is it okay to use C++ templates?

template< class _DevType>
class CDevice{...

template< class _DevType>
void CDevice::Regist(_DevType* pDev)
{
  _pDev = pDev
  ...
}

Hey, I don’t know what CDevice is.

druboy

Add a CDeviceManager class to manage all devices, CWhat contains CDeviceManager

druboy

If it is not an obvious Is-A relationship, it is recommended to use inheritance less than members.

barstear

to:sky_hexia
I am trying to save trouble and not write each one. CDevice refers to CDevice1 CDevice2 CDevice3. Each implementation is the same as it.
void CDevice::Regist(IDevice1* pDev1)
void CDevice::ThreadCallBack()

in reality:
void CDevice1::Regist(..){...}
void CDevice1::ThreadCallBack(){..}
void CDevice2::Regist(..){...}
...
to:koby806
Ha ha, in fact, simply put: there are many different types of equipment on the periphery.If you want to interact with a central hub module, how can you design it?
Make the structure loose, concise and efficient.
Ha ha, this is a very challenging problem, loose is not necessarily concise, just like each device defines an interface, CWhat inherits these interfaces, and then defines multiple device interfaces to allow the device to inherit (such as implementing interactive calls). (a public interface (It doesn't work, first the semantics don't work, and then the method parameters are also different).

to:druboy
If CDeviceMgr is the role of Proxy, then it will become very huge (it can be imagined to implement more than 10 types of various functional functions...);
If you use the member method, when interacting with CWhat, the situation above is inevitable. :(

In fact, I have two purposes for this consideration:
1. When the hardware of a certain type of device is updated, I can easily replace CDeviceX without modifying other modules of the system (that is, loose coupling)
2.CWhat is the heart-level control core should be kept simple and not complicated on a loose basis.

爱德华德

After a while, CDeviceX, after a while, IDevice, after a while, CWhat, what is the relationship between them? Seeing dizzy, can you elaborate clearly?

raccoon1982

I don’t understand why there must be many interfaces. The interfaces of the same type of devices should be the same. The difference is generally just parameters. The problem of parameters is not originally a problem. It can be solved with structural parameters. The structure type can be very flexible originally, set a base class, use the base class pointer as the parameter transfer, and then cast it to the required structure type when using it. If you are unsafe, you can also set a virtual interface in the base class to illustrate the The actual name of the structure class is determined based on this virtual interface before each forced conversion.

barstear

to:爱德华德
CDeviceX is one of CDevice1 CDevice2..., x, one.
IDevice is the same as CDevice, explain to:sky_hexia
In fact, these are not important, what is important is what structure or pattern is used to construct that graph.
For the purpose of the design, what I said above is straightforward.

to:raccoon1982
...Is like this: every device class can be understood as a driver of the operating system!! CWhat is the OS, to achieve "two-way" communication with the driver: that is, CWhat needs to actively adjust the Device, the Device also interrupts when an interruption occurs It must be reported to CWhat. This analogy is very similar to the current situation, which is the design of the two-way interaction between the underlying device and the upper OS.