Correct style for setters and getters in abstract classes?
Hi, just to check, is this the correct style to use variables in abstract classes?
publicabstractclass animal{
protected numLegs;
public getNumLegs{return numLegs;}
}
--
publicclass humanextends animal{
public human(){
numLegs = 2;
}
}
Am I right in using protected? Would default be any better? And since "human" is a "animal", I should be doing abstract + extending, and not using interfactes, right?
Thanks!
[1041 byte] By [
Asbestosa] at [2007-10-3 4:18:42]
I'd probably make the member variables private, and if subclasses need to access them, use protected getters and setters.
I can't recall ever having made member variables anything other than private or public, except once I think I made them default (package private) for a simple data container that was just for that package.
jverda at 2007-7-14 22:20:26 >
> I'd probably make the member variables private, and
> if subclasses need to access them, use protected
> getters and setters.
So, if I were to re-write the code above with a private variable, I assume I'd do something like this:
public abstract class animal {
private int numLegs;
public int getNumLegs { return numLegs; }
protected void setNumLegs(int numLegs) {
this.numLegs = numLegs;
}
}
--
public class human extends animal {
public human() {
this.setNumLegs(2);
}
}
Is that right? This seems rather more complicated -- why use private instead of default? Won't the two versions produce the same result?
Actually in this case since an "animal" object must have some value for the "legs" member, it's more appropriate to have an "animal" constructor which sets the legs member upon construction. Your "human" constructor would then invoke the "super" constructor, passing it the appropriate value for legs.
It doesn't make sense that after construction someone could change the legs member either probably, so "setLegs" shouldn't be part of the API (at least not publically). At least you made yours protected, but should be part of the construction instead.
> Is that right?
No absolute right or wrong, really.
> This seems rather more complicated --
> why use private instead of default? Won't the two
> versions produce the same result?
I prefer to keep the implementation of an object's state private. True, straight get/set doesn't really provide any encapsulation, but there are some cases where it makes a difference. For example, as someone suggested, supplying legs in the constructor and not allowing them to change.
jverda at 2007-7-14 22:20:27 >
This simple example doesn't have enough complexity to really show why you should use private variables. From the point of view of having class human set the number of legs to 2 in its constructor, even your protected member variable example "works". However, when you want to expose your classes as an API to some 3rd-party code, you need to make sure that all data manipulation is performed through methods rather than directly manipulating member variables.
A good example of the importance of this style is in J2EE where an Entity bean will generate getter methods at runtime which correspond to the persistent fields in the database. There isn't a private variable which corresponds with the getXXX methods, so the method is the only way to retrieve the data. Also, because a method is used rather than a variable, you can also specify access permissions to each method. Thus you can create fine-grained access control to a database by preventing certain users from reading or writing specific fields. A simple assignment to a variable could not involve this much security.
Brian
