Disregarding the fact that making variables protected
can be convenient, is there anything that actually necessitates the existence of protected
?
One of the Java coding best practices involves simply using the getter and setter approaches in Java. Below are some advantages of getter and setter over public fields 1. The getter and setter method gives you centralized control of how a certain field is initialized and provided to the client, which makes it much easier to verify and debug.
Check this out stackoverflow.com/questions/2279662/… Even if you use getters and setters (which I personally would - I almost always keep fields private) that doesn't mean that protected becomes pointless... it just means that you're likely to make the getters and setters themselves protected rather than the variable.
Even if you use getters and setters (which I personally would - I almost always keep fields private) that doesn't mean that protected becomes pointless... it just means that you're likely to make the getters and setters themselves protected rather than the variable.
I think we are confusing bad practice with the role of getter/setter. Bad practice is everywhere. But when you are using a getter/setter you expect to give a certain value and get a certain value. You know you are setting a string. You will get a string. Thats the role of the getter/setter.
Even if you use getters and setters (which I personally would - I almost always keep fields private) that doesn't mean that protected
becomes pointless... it just means that you're likely to make the getters and setters themselves protected
rather than the variable.
If your question is really about whether protected
accessibility is useful at all, I'd say it is - it often makes sense to have a member which is only accessible to subclasses. More than that, I sometimes use a protected abstract method to which is called by the superclass, but isn't accessible outside the hierarchy.
For example, in the template method pattern you may well have a public method which does some setup, calls a protected abstract method, and then perhaps does some final work too. You don't want the abstract method to be public, because you want to make sure your start/end code is executed... and you don't want to force that code to be called by subclasses explicitly.
Consider you want to make a class car
which contains a variable fuel. You don't want this variable be set from outside directly, because fuel usage depends on the car. However, if someone extends car
, they should be able to modify it.
class Car {
protected float fuelLevel;
public float getFuel() {
return this.fuelLevel;
}
public void drive() {
this.fuelLevel -= 0.5; // fuel usage of an average car
}
}
class Ferrari extends Car {
public void drive() { // override drive method
this.fuelLevel -= 2; // obviously, a Ferrari consumes much more fuel!
}
}
You could also do the same with a protected void setFuel(...)
method.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With