in the tutorials it is suggested to not extend Node, and use UserData instead, Do you guys have any idea why we should do that?
source :
You want to add custom accessor methods to a spatial? Do not extend Node or Geometry, use Custom Controls instead. You want to add custom fields to a spatial? Do not extend Node or Geometry, use the built-in setUserData() method instead. Where ever the Spatial is accessible, you can easily access the object’s class fields (user data) and accessors (control methods) this way.
General advice: “prefer composition over specialization”
Almost always, it’s better to use a control or user data to add functionality to a Node instead of extending it. For one thing, if you do it that way then you don’t care how the node was created. If you load a model from disk then you can still add the behaviors to it.
Check out this, it should make the advantages of composition obvious (and at the same time show the shortcomings of extension, it could not even do this)
@pspeed said:
General advice: "prefer composition over specialization"
Almost always, it’s better to use a control or user data to add functionality to a Node instead of extending it. For one thing, if you do it that way then you don’t care how the node was created. If you load a model from disk then you can still add the behaviors to it.
Let’s pretend for a second that I’m super dense (because I am).
Please correct me but is this another way to put it?
Don’t extend Node or Spatial. Do extend AbstractControl. We’re still relying heavily upon specialization, but doing it this way is in accordance with the manner the engine has been built?
Is it ok (a.k.a good practice) to have 60+ implementations of AbstractControl, each doing whatever you need to make your game’s spatials do their things?
@Normen - Thanks for the demo. That is awesome stuff. Very helpful.
Question 1: Is the demo (a.k.a. Millcraft :)) src available somewhere?
Question 2: What in the name of Normen is a Quixote?
@new-Thrall said:
Let's pretend for a second that I'm super dense (because I am).
Please correct me but is this another way to put it?
Don’t extend Node or Spatial. Do extend AbstractControl. We’re still relying heavily upon specialization, but doing it this way is in accordance with the manner the engine has been built?
Is it ok (a.k.a good practice) to have 60+ implementations of AbstractControl, each doing whatever you need to make your game’s spatials do their things?
I guess… but extending AbstractControl is just a convenience to implement the Control composition interface that’s available. You aren’t extending node, you are adding pluggable behaviors to it. The AbstractControl/Control thing is just an implementation detail.
As in: you should not start and make the same extension mistake with Controls I did that mistake in MonkeyZone and thats the only thing where it gets convoluted.
@pspeed, @normen: OK I think I’m picking up what you guys are laying down. This is good stuff. I really appreciate you guys taking time to help us all grasp the bigger picture.
I did that mistake in MonkeyZone and thats the only thing where it gets convoluted.