Abstract data communication in modular design

Question

I'm doing the analysis for a software which I've had in mind for a long time. Its purpose is to turn sound into an image, apply graphical transformations on it, and turn it back into sound to hear the result. I plan to write it in C++ and I want to make it as modular as possible. As I am relatively inexperienced in modular design, my approach to the problem may be naive.

The app would be an assembly of several Modules which have DataInputs and DataOutputs that could be connected to each other. Basically, when a module has some data to send, it can tell one of its outputs to send a DataBlock to all of the inputs it is connected to, and these inputs would store the data block until their own module tells them to read it for further processing. This yields the following class diagram (excerpt):

class diagram summing up everything

The part I'm really not sure about is which type the inner data (DataBlock::data) should take. Up to now I've put void* as a type because it would allow me to statically cast it back into anything I want it to be without much trouble, but for many reasons which I'm not going to enumerate here, this is obviously not a solution I want to go with. A solution I've also come up with is to make an abstract BaseData type which any concrete data type would inherit from, like so:

alternative solution

I think this would be an okay solution, but I'm concerned about using inheritance "just" to make it so concrete data types have something in common while they represent completely different stuff. With this solution, modules would have to handle data blocks differently based on their type (given by the DataBlock::dataType field), which I think is fine if done correctly.

What is this design worth? Am I headed in the right direction or am I going to suffer the pain of a thousand fell gods because of some flaw I overlooked? What are potential alternatives and/or well-known design patterns for that purpose?

• leftaroundabout: What kinds of different types do you want to store in DataBlock? Why is it necessary anyway to store different types that will only be selected at runtime (so it can't be expresses with a simple template)? I have a vague feeling of YAGNI here.
• qreon: As I said my approach may be naive. DataBlocks will store audio samples as well as pixel data, or even commands in some cases. I failed to mention that previously, sorry. IMHO, this could be useful for the audio playback module for example: it needs to receive audio samples to play as well as commands to know when to start and to stop. That's why I think I need different types of data blocks. However, they need to be all passed through the same kind of data pipelines, hence the inheritance from a common abstract type. Can you elaborate on how templates could be used in this case?
• leftaroundabout: Well, if you have one pipeline that only ever transports audio, then it would most sensibly use DataInput<Audio>, which in turn has DataBlock<Audio> which is by the type system guaranteed to only store audio, not something else. — Commands are another thing, and I daresay you should probably handle them in a separate fashion entirely.
• qreon: I haven't thought twice about the fact my pipelines would ever carry only one type of data. You should make it an answer so I can validate it. Thanks a lot! It's a bit off-topic but what would advise me to look into for commands (patterns, etc)?

Answer 1

A base class makes sense, if and only if, you can easily imagine performing operations on things of the type of the base class. In your example above (to the degree to which its fleshed out) - it appears this is not the case.

If I were designing something like the above, I would have each module define whatever API made sense for it, and feel no need to make them have inputs and outputs which could be manipulated generically. I think this is the crux of the problem you've artificially created for yourself.

If - however - you do have good reason to want to treat these three kinds of objects generically, there are two families of good ways to go about that in C++.

• templates
• variant union (tagged union)

TEMPLATES

You can write algorithms (procedures) which operate on an arbitrary 'typename T', and produce whatever types make sense for output.

VARIANT UNION To use a variant union (see https://en.wikipedia.org/wiki/Tagged_union) there are a number of libraries or language features you can use. However, problably the least weak approach would be

- https://en.cppreference.com/w/cpp/utility/variant
 I'm not too fond of this approach, as its syntactically quite ugly.

• qreon: I'll look into templates more precisely, thanks for the hint. I did think about them but couldn't see how to use them, @leftaroundabout clarified it in the comments above. :)
• Lewis Pringle: I'm not sure templates are a good fit for what you've described, but they maybe at some point. Templates work well for an algorithm IF AND ONLY IF you can imagine writing a procedure DoSomething(T element) { ... do soemthing to each element which might be from different models; } This CAN happen (like sort() is a good example of something like that).
• Lewis Pringle: If you are not used to using templates, a good way to start is to WAIT until you see you are writing duplicative code. When you see the same patterns over and over again, templates are a good way to capture that and reduce the duplication. But I think they maybe just a source of confusion in the early object oriented design phase.