Back to General and Gameplay Programming

OO Design and avoiding dynamic casts

Frank Sullivan · 2012-09-21T05:58:52

Greetings, all. I've often found it difficult to avoid dynamic casts in my designs, and I was wondering if we could brainstorm what strategies one could use to minimize their use. I would find that tremendously productive. One instance that comes up a lot is with the Abstract Factory pattern and its variants. An often-used illustration of this pattern is found on Wikipedia: http://en.wikipedia....act_factory.svg Now, I would make this a little more complex by saying that the GUIFactory interface would also have methods for creating other controls, like createComboBox and createList. It may also have something like createWindow. And the Window interface might have an addControl method that can be used to add buttons/comboboxes/lists to the window. So, the trickery comes when you're writing your concrete implementations. Let's imagine an imaginary GUI framework called Foo32 that you want to target. So you write FooFactory and concrete product classes like FooWindow, FooButton, FooComboBox, FooList, etc. So, the class hierarchy would look something like this: [attachment=11211:foo.gif] And the factory would look something like this: [source lang="cpp"]class FooFactory : public GUIFactory { public: FooWindow* createWindow(); FooButton* createButton(); FooList* createList(); FooComboBox* createComboBox(); };[/source] And here are some possible class definitions for FooButton and FooWindow: [source lang="cpp"] class FooButton : public Button { Foo::Button *m_button; // The actual button object. public: FooButton(); // Button interface void paint(); }; class FooWindow: public Window { Foo::Window m_window; // The actual button object. public: FooButton(); // Window interface void paint(); void addControl(Control *ctrl) { m_window.addControl(ctrl); // Error! Control is not a Foo::Control } }; [/source] So the question is, how to solve that error. The naive approach would be to just test and see what concrete class we're dealing with. [source lang="cpp"] void addControl(Control *ctrl) { FooButton *fooButton = dynamic_cast<FooButton*>(ctrl); if(fooButton != NULL) { m_window.addControl(fooButton->getFooButton()); // getFooButton returns the Foo::Button* } FooComboBox *fooCB = dynamic_cast<FooComboBox*>(ctrl); if(fooCB != NULL) { m_window.addControl(fooCB->getFooComboBox()); // getFooButton returns the Foo::ComboBox* } /* and so on... */ } [/source] Ouch, though. I suppose I could use multiple inheritance, i.e. FooButton would inherit from both Button and Foo::Button. Since Foo::Button is a Foo::Control, then the method implementation is simplified: [source lang="cpp"] void addControl(Control *ctrl) { Foo::Control *fooCtrl = dynamic_cast<Foo::Control*>(ctrl); if(fooCtrl!= NULL) { m_window.addControl(fooCtrl); } } [/source] Problem is, this uses multiple inheritance and we still have a dynamic_cast. I've spent enough time debugging dynamic_cast to know that it is not a quick or trivial thing (with MSVC, it does multiple strcmps). Perhaps that's not a problem for setting up a GUI (most of this is done during program initialization and GUI's typically spend most of their time waiting for user input anyway). But what if the above pattern is needed for something other than a GUI -- something for a real-time video game that requires dozens or hundreds of Control-like objects to be added and removed from a Window-like object each frame? I am currently wrestling with a situation just like that -- a have a "View" (analogous to Window) that needs to have "Scene Objects" (analogous to Control) added to it. Examples of Scene Object types are Model, Particle System, Hud Element, etc. I feel that it is necessary to use something like an Abstract Factory because of a high possibility that I may want to change what graphics framework I'm using someday (I'm currently using OpenSceneGraph). It's often said that, if you are using dynamic_cast a lot, you're probably doing something wrong. This makes me feel uneasy about my design. It's also often said that your classes should be open for extension and closed for modification. I find it really difficult to close classes like GUIFactory, because one is always thinking of new types of controls that need to be created. Maybe a createTextBox method needs to be added at some point -- is it really desirable to subclass GUIFactory just because you want to call it 'closed'? I'm getting better and better at OO design, but I'm still fledgling in a lot of ways, and as you can see, I could use some advice. From where I sit, there are two basic possibilities: 1) Don't try to abstract the graphics framework in something like a game, where performance is critical. 2) Minimize the amount of time that the code sequence crosses your abstraction layer, i.e... [source lang="cpp"] // This code can't know we're using Foo32. It just knows about the abstract interfaces. // The typical way to do it... Window w = guiFactory->createWindow(); // returns a FooWindow, but this code doesn't know or care Button b = guiFactory->createButton(); // returns a FooButton, but this code doesn't know or care w->addControl(b); // this will do a dynamic_cast (slow) // Here is an alternate possibility and gets around the above issues... int windowId = guiFactory->createWindow(); // returns the id of the created window, but the factory keeps the window for itself int buttonId = guiFactory->createButton(); // as above, only the id of the button is returned guiFactory->addControlToWindow(windowId, buttonId); [/source] Since FooFactory is owning the objects it creates in that second solution, it has concrete references to them, and thus no casting is needed. This has a very messy, non-OOP feel to it, though. Almost as if I'm working with OpenGL.

General and Gameplay Programming Programming

Started by CDProp September 11, 2012 06:19 PM

22 comments, last by Xai 11 years, 7 months ago

dmatter

4,872

September 13, 2012 11:59 AM

Essentially, it would be nice to have a system where you can change the effect without changing the material, and everything still works as long as the material provides the necessary inputs to the effect.

As you demonstrated in your first example a material has no behaviour and in particular no polymorphic behaviour, this is why you gave it an empty interface. If something has no behaviour then it's just data. The problem then becomes how to model that data so as to meet your goals.

If we recognise that there are only a few different kinds of thing that any effect could possibly ever want from a material then all we have to do is design a Material class that is able to provide any and all of those different things to an effect:



class Material

{

public:

	 const vector3 & getVector(const std::string & propertyName) const;

	 const matrix44 & getMatrices(const std::string & propertyName) const;

	 float getScalars(const std::string & propertyName) const;

	 // etc

};

Now you're in a position where you model different types of material in a data-driven fashion; a Material is a "ColorMaterial" not because you subclassed it but because you populated it with ambient and diffuse properties.

Edit: Annoying that the Code tags don't format indent properly, I always have to fight with it to get things aligned.

David Gill :: GitHub :: twitter .

kloffy

1,319

September 13, 2012 12:19 PM

Yes, I have considered this approach as well (but I didn't want to make my post any longer). It certainly has some good arguments going for it (and the empty material base class felt wrong from the beginning). However, the nice thing about using inheritance is that I can use a cast to make sure a certain set of properties will always be present. Once the dynamic cast succeeds, I can access them very efficiently, whereas - if I understand correctly - in your data driven approach, I would have look them up in a map. But I agree, this is kind of an "abuse" of inheritance without any real polymorphic behaviour and it brings some weirdness with it.

CDProp

1,451

Author

September 13, 2012 09:47 PM

An OpenGL window should not be running around casting OpenGL controls to a long list of all possible children types, that is just madness. That is an unmanageable, unextendable non-oo design. However each OpenGL control can and likely will cast the IWindow to an IOpenGL window (fully expecting it to be one, since the whole assumption is the creation of everything from exactly 1 factory instance, so that a mismatch would be impossible. Also, an OpenGL window would keep a list of IOpenGL controls, and cast each control on add from IControl to IOpenGL control ... because the open gl family is going to be implemented internally to receive, associate with and use only other open gl family controls. The base interfaces are just used as the lesser API for externally facing interfaces.

Keep in mind that my casts "to a list of all possible children types" was an illustration of what not to do. Then, I offered another solution that is very similar to what you proposed:

[source lang="cpp"]void addControl(Control *ctrl)
{
Foo::Control *fooCtrl = dynamic_cast(ctrl);
if(fooCtrl!= NULL)
{
m_window.addControl(fooCtrl);
}
}[/source]

There is a problem with this, though. It works, but there is a bit of ugliness which I can't seem to get around, which is that it almost inevitably requires multiple inheritance. Here is one possible hierarchy (this time using OpenGL as an example, as you did).

OpenGLControl could also derive from IControl, but then you'd have diamond inheritance. You could use virtual inheritance to solve that; in fact, it's probably a good idea to do that anyway, because if your hierarchy gets any deeper (think ISwitchButton and IRadioButton), you're going to end up with diamond inheritance anyway. Once you have diamond inheritance, virtual inheritance becomes and issue, and once you have virtual base classes, you can no longer downcast them using static_cast, which means that SiCrane's checked cast solution is out of the question.

So, let's suppose that you keep your hierarchy clean enough that there are no diamonds, and thus virtual inheritance is unnecessary. Well, you still have multiple inheritance, which lends overhead to dynamic casting (and static casting too, if I understand it correctly) because now you have multiple vtables in your object, and a cast involves offsetting the pointer.

These are the sorts of ugly sins that I've been dealing with with this design.

I am warming up to Telastyn YAGNI remark. As jwezorek said, it may be impractical to think that I can wrap everything that I need to, even future frameworks that I haven't thought of yet.

dmatter, thank you very much for your reply. It seems to be clearest way to put into words what I'm doing wrong. The duck typing idea sounds intriguing, but I think my project is a bit too complicated for that. Your idea for having the window produce controls is also intriguing. It seems like it would be difficult to ever close the Window class to modification, though, because every time you come up with a new control type, you have to add a new method. Still, that may be a lesser sin than violating LSP.

Xai

1,851

September 21, 2012 05:58 AM

You missed exactly 1 thing in my example CDProp. The OpenGL Window does NOT have a list of IControls, it has a list of IOpenGLControls. So your original example (with multiple inheritance and/or dynamic_casting still needed is OK, even for a 500 object inner loop of a game engine, if and only if the dynamic_casts can be amortized by being NOT in the read / render, but instead in the add ... this is just like having indexes on a db that hurt insert / update but speed up search. But if every frame you are rebuilding or completely reorganizing your objects - then it would not perform well. But the goal of this design is that the casts are AT ASSOCIATION TIME, not AT USAGE TIME.

This design is simply does of course require the key interfaced based programming techniques. So as you mention the diamond problem, multiple inheritance, virtual inheritance, etc. all come along for the ride - stealing a little cost here and there, but hopefully applied judiciously they benefit will outweigh the cost.

OO Design and avoiding dynamic casts

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

OO Design and avoiding dynamic casts

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines