Question

I tend to have a class to describe a general concept and subclasses to describe variances in that concept. For example, Polygon <|-- {Rectangle, Triangle, etc.}.

However, I often find I have various representations of these hierarchies. For example, I want to keep the graphical representation (eg, a QPolygon), or the physical representation (mass, centerOfMass), etc. separate from another representation I have.

In my case, I have a hierarchy of purely-data objects (Command <|-- {WaitCommand, UnknownCommand, etc.}) and I have a matching GUI representation for each of the data classes (WaitCommandPanel, UnknownCommandPanel).

My problem is that once I construct the data representation I need to make the leap from the data to the GUI.

Given a list of data objects, I want to be able to construct the corresponding GUI elements but keep the two representations separate.

One [lousy] solution would be for each Command to have the ability (ie, Command::getPanel()) to return its GUI representation. I don't like this because my data classes now have representation code in them.

The other solution (which I've adopted for the time being) is to do a lookup. That is, when initiating the GUI, given a list of Commands (the generalization), the function determines what object to create based on its specialized type. I don't like this either.

Any suggestions?

No correct solution

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top