Java – Why Is There No ‘Subclasses-Only’ Access Modifier in Java?

inheritancejavalanguage-featuresobject-oriented

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.

Best Answer

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 N² 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.

Related Solutions

Java Coding Style – Should Default Access Modifier Be Used?

2 things here:

don't use globals :)
it's common/best practice to assume all fields are private unless there's an overriding reason to make them anything else, in which case the most restrictive access should be chosen (usually protected).

Of course there's always exceptions to the rule, but that's the basics to start out from.

Java Access Modifiers – Why Are Protected Members Accessible to Same Package Classes?

looking for a specific use case where both a subclass and a class within the same package needs to access a protected field or method...

Well to me, such a use case is rather general than specific, and it stems from my preferences to:

Start with as strict access modifier as possible, resorting to weaker one(s) only later as deemed necessary.
Have unit tests reside in the same package as tested code.

From above, I can start designing for my objects with default access modifiers (I would start with private but that would complicate unit testing):

public class Example {
    public static void main(String [] args) {
        new UnitTest().testDoSomething(new Unit1(), new Unit2());
    }

    static class Unit1 {
        void doSomething() {} // default access
    }
    static class Unit2 {
        void doSomething() {} // default access
    }

    static class UnitTest {
        void testDoSomething(Unit1 unit1, Unit2 unit2) {
            unit1.doSomething();
            unit2.doSomething();
        }
    }
}

_{Side note in above snippet, Unit1, Unit2 and UnitTest are nested within Example for simplicity of presentation, but in a real project, I would likely have these classes in separate files (and UnitTest even in a separate directory).}

Then, when a necessity arises, I would weaken access control from default to protected:

public class ExampleEvolved {
    public static void main(String [] args) {
        new UnitTest().testDoSomething(new Unit1(), new Unit2());
    }

    static class Unit1 {
        protected void doSomething() {} // made protected
    }
    static class Unit2 {
        protected void doSomething() {} // made protected
    }

    static class UnitTest {
        // ---> no changes needed although UnitTest doesn't subclass
        // ...and, hey, if I'd have to subclass... which one of Unit1, Unit2?
        void testDoSomething(Unit1 unit1, Unit2 unit2) {
            unit1.doSomething();
            unit2.doSomething();
        }
    }
}

You see, I can keep unit test code in ExampleEvolved unchanged due to protected methods being accessible from the same package, even though accessing object is not a sub-class.

Less changes needed => safer modification; after all I changed only access modifiers and I did not modify what methods Unit1.doSomething() and Unit2.doSomething() do, so it is only natural to expect unit test code to continue run without modifications.

Best Answer

Related Solutions

Java Coding Style – Should Default Access Modifier Be Used?

Java Access Modifiers – Why Are Protected Members Accessible to Same Package Classes?

Related Topic