You’ve been lead astray 
Seriously, any large commercial project will require those sort of coding standards as otherwise things tend to descend into spaghetti very fast.
1 Like
@zarch said:
It's about abstraction. By having the access through the getter/setter it means that if you change the behaviour of the class then you can do it inside the class without changing anything that uses it.
I don't fully agree, I think there is a relevant OO distinction between using an object through get/set (composition) and being and object of a class. Your application class is a SimpleApplication meaning that you have to know how to behave like one. Therefore you can access the protected members, that is why the keyword is in the language. I do not think best practice encourages you to use acessors to get at your own internal state. I'd think best practice is rather using acessors instead of public fields when accessing another object. That's my 2 cents.
But as long as the documentation is correct either way is fine :)
1 Like
@jmaasing said:
I don't fully agree, I think there is a relevant OO distinction between using an object through get/set (composition) and being and object of a class. Your application class is a SimpleApplication meaning that you have to know how to behave like one. Therefore you can access the protected members, that is why the keyword is in the language. I do not think best practice encourages you to use acessors to get at your own internal state. I'd think best practice is rather using acessors instead of public fields when accessing another object. That's my 2 cents.
This is partially true. Generally, protected should only be used for elements that are designed for extension. Otherwise, exposing protected fields to subclasses is breaking encapsulation. Even in JME's case, it's possible to really screw with SimpleApplication by directly messing with its protected fields. They weren't designed for extension. They were included to save a little typing... which in general is not a good excuse for a design decision.
It's quite common to have protected getters, for example.
2 Likes
@pspeed said:
This is partially true. Generally, protected should only be used for elements that are designed for extension. Otherwise, exposing protected fields to subclasses is breaking encapsulation. Even in JME's case, it's possible to really screw with SimpleApplication by directly messing with its protected fields. They weren't designed for extension. They were included to save a little typing... which in general is not a good excuse for a design decision.
It's quite common to have protected getters, for example.
Exactly.
And in fact we have an example in this very forum right now:
http://hub.jmonkeyengine.org/groups/physics/forum/topic/collision-point/
An entire thread that turned out to be because someone rotated the root node. That's something that no-one expects people to do and there is no valid reason to do - but because the root node is not immutable for transformations it allows people to do this and break things in unexpected ways.
I’m not fond of this way of thinking…i usually prefer making people understand why it’s dumb to do something instead of forbidding them to do it.
You never know when a dumb thing might come in handy.
@nehon said:
I'm not fond of this way of thinking....i usually prefer making people understand why it's dumb to do something instead of forbidding them to do it.
You never know when a dumb thing might come in handy.
Careful, that slippery-sloped argument can be used to make all fields public. :)
The truth is that any right answer requires more design work. Without it, either fields are protected and the class potentially breaks at the slightest provocation or fields are private and someone bangs their head against the wall because they are unable to do a simple thing that the designers didn't think of. (I'm looking at you lobo browser!)
JME plays fast and loose with protected fields and it's a pretty widespread. JME trusts the developer to know a bit about what they are doing to avoid shooting themselves in the foot. I actually like that. But it's also why I take a pretty hard stance on approachability for a Java-newb. Know Java pretty well or forever struggle.
At any rate, this is not the kind of thing that can be easily rebottled. These protected fields are here to stay... so they should be included in the javadoc. (They are currently filtered out or not turned on or whatever in the javadoc target settings.) Along with big hairy "don't set this field yourself" text.
I agree they should be documented
Well, if there is something I’ve learned to avoid doing mistakes, is not to use protected members unless you know where you are entering. If you are using a protected member, in my head it’s suposed that you know what that member does, and how it fits in it’s ancestor.
I tend to use protected members for my classes that add functionality to it, like classes that are abstract. Normally they need some private logic, but I tend to use protected members for the logic extending ones. I may need to revisit that concept, as some of the arguments shown here are quite good to encourage the using of getters/setters for those fields.
They are now available in the javadoc
4 Likes