Casting - bad design?

[JVene]

The casting operators are there to be used, to be sure, but not without good cause.

Obviously that begs the question, "What is a good reason to use casting?"

I'm not sure I have a great answer for that, but for your design issue, I have some thoughts.

First, it seems that while there's very little in common between the derived classes, perhaps a minor commonality can be invoked.

The commonality may be nothing more than a virtual function "void DoYourStuff()".

Instead of assuming the GUI must select an item from a container and cast it in order to make specific calls, you can call a virtual "Do" function, which in turn calls an overload in the GUI - which effectively selects WHAT can be done based on type. No casting required - you're relying on the fact that at the point of the virtual function, it 'knows' what it is, and informs the GUI of that through the overloaded callback.

In case I'm not clear, GUI runs through a container, calling the "Do" function knowing only the base class type (and possibly providing a reference to the device context, the GUI object, etc). The "Do" in turn calls back to GUI, with 'this' as a parameter, which identifies the type - from there you have specific 'knowledge' within the GUI object of the type, and can make very specific calls to that object.

This does bring to mind the question as to which object does what....

You may have the viewpoint that GUI code does the drawing, and therefore the code that displays information, or provides GUI interfacing, is in the GUI objects. You could also have the view that these objects should do that themselves, using GUI objects as tool to do the work.

I have a situation where I have a collection of objects with few common elements, and lots of uniqueness in the derivatives. I have a list of them, the user may select one in a list, and the content of the dialog will change (sometimes drastically) to reflect the options of that item.

This is a little like a tabbed dialog, but without tabs on display. Due to the nature of our framework, these dialogs aren't taken from a dialog resource - long story on that - the bottom line is that we select an object based on the type the user selected in the list, and as I described above, the base has just a "virtual void select()" function which supplies that type in the descendant code - selecting an object which represents the appropriate dialog. That object, in turn, maps the unique elements to UI controls - etc, etc....

I have other situations where something similar happens, but some of the objects should not or can't be derived from a common base. These objects are so dissimilar that it defies the notion of a container capable of referencing them in a common base. Depending on the containment issues, I choose to create a 'mapping' object. The container has nothing to do with the target objects - it's just a virtual base for the 'virtual do' function(s). Descendants of the base mapper are created for each special case - I call 'do' on the base, the descendant calls whatever is appropriate for each special case on these otherwise unrelated objects.

Now I'm rambling.....