[SOLVED] Inherit Drawable or implement Draw() in SFML.net 2?

[laserbeams]

Edit for future readers:  I was initially unclear, and should have mentioned that I was using SFML.net 2.  Inheriting from Drawable is not possible in SFML.net 2.  This thread explains why. -end edit-

I've seen people ask how to do this one way or another, but I'm not experienced enough to know if there are any big problems with doing it either way (I'm a SFML neophyte).

I want to be able to render a list of simple and compound objects easily, which seems to mean choosing one of these two options.  Ignore bad syntax:

Code: [Select]

for each (object in objectlist) {
    window.Draw(object);
}

for each (object in objectlist) {
    object.Draw(window);
}

So either I build all of my compound objects (e.g. a button consisting of a background shape and a text label) as inheriting drawable, and throw those objects into a list with other basic drawable objects like sprites... or I implement my compound objects with a Draw(window) method, along with giving simpler objects like sprites a wrapper, so I can use sprite.Draw(window) as well.

I suppose different lists could be kept for simple and compound objects, depending on what was being drawn (and I will no doubt have multiple lists anyway), but switching between drawing methods depending on the object type seems kludgy.

Does anyone have any suggestions on why one method might be better?

[Laurent]

sf::Drawable is not just about being able to write "window.Draw(object)". It brings a lot of functions into your derived classes:
- set/get position
- set/get rotation
- set/get scale
- set/get color
- set/get blend mode

The real question is: do these functions make sense in all your derived classes?

[laserbeams]

Probably not in all - likely no need to rotate a menu button, for example - but for game objects, everything but blend mode would probably be beneficial for my purposes.  If I implemented Draw(window) I'd have to handle all that slightly differently, but it'd still be possible.

I was wondering if there was an advantage to doing them all one way or the other.

edit: I guess that somewhat answers my question - if I did them all with Drawable, I'd have more standardized access to position, rotation, etc. rather than implementing everything all differently.

[Nexus]

Generally, you should try too use the weakest coupling possible. Inheritance is relatively strong and implies class dependencies. I would only use it if the relationship is really meaningful and of relevant advantage. Search for the Liskov Substitution Principle to get more informations...

[laserbeams]

Thanks for your replies, Laurent and Nexus.  Especially your very speedy one, Laurent!

To a less experienced programmer as myself, it doesn't seem like there's a clear and simple answer to the problem of handling the drawing of a compound object within SFML.  After Laurent's answer made me question my assumptions, I thought inheriting drawable was clearly a good choice.  Now you make me question that again!

The LSP article goes over my head a bit, but I can see where my example of a button - or an even more complex game object such as a vehicle - would probably not violate the LSP if inheriting from drawable.  Inheriting from either sprite or shape would violate the LSP.  Buttons and vehicles are both inherently drawable objects to my thinking, and at least make sense with the other functions Laurent mentioned above.

However, after my first response, I did spend some time to think about other ways a compound object could be handled.  The other method I could see working would be to have the object manage its simple drawable parts in a list of everything to be drawn in a given frame, completely separating the drawing responsibility from the object itself.  A button could add a Shape and a Text to a list of all things to be drawn, updating via reference as necessary, or removing its drawables when it is destroyed.  Is this what is meant by separating model and view logic?  Would that be considered weak coupling?  It seems like it would create more chances for things to go wrong, like having difficulty managing draw order.

Would the weakest coupling in this case be having each compound object draw its own component parts when asked?

[laserbeams]

So, apparently it's impossible to inherit drawable if using SFML.net?

Code: [Select]

internal abstract void Render(RenderWindow target, Shader shader);

Since it's internal, nothing outside the SFML.Graphics assembly can inherit from Drawable, or any of its children.  Is this intended?  It appears that if it weren't marked internal, my overrides would work.  I didn't discover that Render was internal (or even know what internal meant) until I'd gone through overriding all the rest of the Drawable functions and it still didn't work.

Now I find this:  http://www.sfml-dev.org/forum/viewtopic.php?t=4569

I guess I'll have to do everything a different way after all?

[Laurent]

Yes

[laserbeams]

It's not what I'd planned on originally, but this has led me to thinking about other ways to accomplish what I want, and I think I will adopt a component based approach, with another small class managing the drawables for each game object.

I now see what you meant by weak couplings, Nexus.

Thank you both, this has been a learning experience!  I will mark the topic as solved.

Summary for future visitors searching for information on this topic:  In SFML.net 2, you cannot inherit from Drawable (or Sprite, Shape, or Text).  And while you can probably do it in the C++ version, it might not be a good idea.