Design philosophy: individualized signals for groups of requests or generalized signal
ronM71 last edited by
I have a controller class.
It "controls" many instances of other classes.
each controlled class can send 10-20 types of requests to the controller class.
The controller class needs to respond back to each caller, Asynchronously. Forget the sync mechanism. Already got it working.
I can do it by either:
Each controlled class will define its own signals, each with its own payload, connect them to parallel slots in the controller and emit. The controller will have signals for each type of request and in turn, will emit the response back at the original calling controlled object.
Define a standardized "RequestResponse" class with common payload (type, caller object ptr) from which other sub-classes can derive for more elaborate payloads. Have a single type of signal for all controlled classes aimed at the controller, and shoot messages at the controller. The controller will have a single signal that shoots a message back.
with #1. I will have to do very elaborate "connect" work. It will be precise, but tedious. With #2, I am at the risk of controlled object #1 getting slot calls for responses aimed at controlled object #2. I can filter things out by type, called object ptr, but still, redundant calls will be invoked. Complexity however will deminish.
What would you do?
Franzk last edited by
The approach would depend on the exact type and nature of communication. Signals are like shouting at the sky, maybe someone does something with it, maybe not*. If that fits your design, then you should go for that approach. Else do something that involves events (easy to ignore, but no sender) or direct calls as in 2.
You could equally well wonder if you really need this amount of communication to your controller object. If it's like a scheduler you very well might need a pointer to it.
*And you shouldn't care either. Expecting a response to a signal would be Bad Style™.
ronM71 last edited by
Perhaps I was too quick to dub this "request/response" as most people think HTTP immediately. It's more like an asynchronous: "Hey, Object A, It's Object B, I got a job for you". and x seconds later, "Hey, Object B, it's object A, I had 10 seconds to work on your request and here are the results".