This might be an X Y problem, but here's my situation.
I've got a QT5 C++ code base whose task it is to allow for the configuration of a "process chain". A "process chain" here means a list of linked elements who execute in sequential order, taking a single input and returning a single output to the next "process element" in the chain. At the end of the chain, this data is saved.
Each process element is configurable, and while each works on the same data and outputs the same datatype, each does something completely different underneath. They take vastly different configuration parameters, but share the same interface. Each has a different constructor, one may take a single float, another a matrix, etc... in their constructor.
There are dozens of process element types which grows with every iteration of the software. Each process element type needs to be serialized (currently through JSON), and needs its configuration to be configured through a gui, to which each parameter to configure may not have the same gui widget type (ie one may need only a line edit, another may need radio buttons, another a spin box, but all configure the same process element).
My problem is that I currently accomplish this in a very coupled manner. The process element class needs to know and define its own JSON format, how to construct itself from json, and it essentially needs to add itself to a global static unordered map of classname -> constructors, and classname -> json formats.
I do not currently have a way to add in the ability to specify gui type, that is what led me to believe that the current method is unsustainable.
My issues with my current approach are as follows:
- I couple the way the serialization works with the class itself.
- I couple the display implicitly (currently all gui types are the same, but now the requirements have changed and require some gui types to be different).
I want to de couple this functionality, but I'm not happy with other possible solutions. Creating a "serialization class" for each process element seems like code smell, and this would have to be duplicated for the visualization. I would also like to avoid doing work that would have to be replicated for each class. Currently I have a macro set up automating the static adding of classname mappings to the global class maps.
What strategies can I employ to solve the design coupling issue I'm having? Ultimately, is there any way in which I can effectively separate serialization and visualization from the "code objects" (process elements) in my circumstance?