What architecture to choose for a Qt program?

Question

OOP

Good afternoon! Prompt what architecture of application it is better to use. There is a task - to write software for control of a piece of iron on COM-port. Several irons. To do this, the config is loaded, which describes the ID of the pieces of iron and their capabilities and available parameters. The required number of knobs and other controls are dynamically loaded from this config, divisors for parameter values ​​are also indicated there (hardware gives out integers, but in real life it is 0.1 or 0.01 fractions of real physical values ​​and the program, knowing the divisors, translates into normal form). There are a few additional windows and menus, but in general, the bulk of user interaction takes place in the main window.
For parsing created a separate object. For settings export and import - separate. A separate wrapper object (QSerialPort) for the com port, etc. Now all these objects are created inside the main window class, and the data from the config is parsed into a large structure, which is passed by reference to various objects that fill it (the parser) or read data from it. This approach looks like a teapot to me (I have little experience in OOP). I ask you for advice and share your experience, opinion. Previously, a lot of hardware in C failed, I want to stop writing C ++ plus C code like this :)) Go more to the canons of OOP.
1. Is it okay to create all these objects and communicate between them in the main window class?? In principle, a lot of data is used and converted specifically for output in this window, and in general it is more convenient than making "a million" signal slots and steering it all in main() outside the main window class.
2. How "in a good way" to do the transfer of the config from the parser to other objects? Through getters? or is it permissible and like this by reference?
I would also be happy to hear other advice on the topic. Thanks to!
ps what literature can you recommend on designing for OOP?

Answer 1

I would recommend:
Suppose the parser parses the config into the settings object, these settings are passed to the factory, which, based on them, will issue correctly configured objects upon request. The link to the factory is passed to the window class, from where dependencies are extracted and passed on to controls by reference. Controls, receiving a dependency (for example, through a constructor), are attached to it via signals / slots or directly call virtual methods.
Bottom line: the interface is decomposed, it knows nothing about the business logic, except for the provided abstract API. Controls know about each other only within the framework of the signals / slots between themselves and the list of dependencies of their children. The business logic doesn't know anything about the interface.