In Java, there are four available access modifiers for methods:
public – any class can use this method.
protected – classes in the same package and subclasses in any package can use this method.
private – only this class can use this method.
no modifier (“package private”) – only classes in the same package can use this method.
What happens often is that I want to have useful methods in a superclass, that all subclasses can use. But it wouldn’t make sense for other classes to access this method, and in a sense it would break encapsulation.
So I have to declare these useful methods in the superclass public or protected, which exposes them to all other classes at least in the package. Even though they’re only meant to be used by the subclasses.
Is there a reason why there isn’t a subclasses-only access modifier in Java? It seems very odd to me. Am I missing something?
Also, a subclasses-only access modifier would also be useful for when you want to expose variables only to subclasses. Which to me happens a lot.
Java originally had such a modifier. It was written private protected but removed in Java 1.0.
I assume that was a judgment call that the extra complexity wasn’t worth the cost.
Every language feature has a cost: in teaching it to new programmers; in documentation; in implementing it in the compiler, JVM, and dev tools; in reasoning about program correctness; in constraining future language evolution; and more. Language features interact with each other, potentially with N2 interactions.
What percent of Java programmers have read through the Java language spec and VM spec? I bet it’s a small percentage, which argues for an even simpler language for the sake of understandability and engineering products that we can depend on
The benefit of the private protected feature was small since the package is the main unit of modularity.
2
Because you can emulate the subclasses-only modifier by using the protected modifier and enforcing that only the parent class and its subclasses are in the same package.
It’s indeed a good practice, because the packages not only help to organize big projects in terms of cohesion, but they also show that the classes in the same package might have some level of coupling.
2
This already exists. It is protected.
You have control over what classes exist within the package. If there is no other class in the package and a given variable or method is protected, it is ‘subclasses only’.
That said, once again, you have control over what classes exist within the package. You can chose to just not use the protected methods or variables.
3
Acess control can be thought of as the result of a coversation with an imaginary developer who is working with your class about the class methods and properies…
YOU: Say you want to do x, you call the method doX..
DEV: Tell me more..what are the arguments?
This is public…
YOU: Inside doX I call …
DEV: Whoa, too much information, I don’t care about that. I just want to know how to use it. Tell me something else.
This is private…
YOU: When subclassing, I have doX and doY call doIt which does..
DEV: Yeah, I gonna subclass, tell me more…
This is protected…
YOU: I’m leaving on on vacation in an hour, I’ll be gone for the next 6 months. The Boss says this puppy is yours! Bye.
DEV: Wait don’t go yet, tell me everything…
This is package.
YOU: The method doItWhen is only called by this class and it hasn’t changed in ten years. It…
DEV: Whoa, we’re down to 50 minutes. Next property, and talk faster.
This is protected private…