The protected Modifier
Going back to our asset management example, we have defined several classes that lie in a single hierarchy. The Asset, BankAccount, and SavingsAccount classes belong to one such inheritance hierarchy. The asset management software may contain another inheritance hierarchy containing classes responsible for accounting. The two inheritance hierarchies may be arranged in two different Java packages—say, asset and accounting, respectively. A certain class defined in the accounting package would need access to the net worth of an asset defined in the asset package. If this class derives from a class defined in the asset package, it would have access to the entities defined in the base class, provided those are declared protected. To understand the visibility of protected members, change the public modifier of the count and setCount members in MyClass of previous post to protected. The class MyClass compiles without error. Both the DerivedClass and NonDerivedClass belonging to MyPackage have access to the protected count and setCount members. However, the NewClass.java file will not compile. It would produce NonDerivedClass compilation errors on the statements shown in the following code snippet:
package myanotherpackage;
import mypackage.MyClass;
class DerivedClass extends MyClass {
void someMethod() {
count = 10; setCount(5); }
}
class NonDerivedClass {
void someMethod(int count) {
MyClass obj = new MyClass();
obj.count = 10; // this does not compile
obj.setCount(5); // this does not compile
}
}
Thus, a protected variable is accessible to a subclass, regardless of its package declaration, and also to all classes belonging to the same package. It is not accessible to a class belonging to another package and that does not inherit from the defining class.
Lastly, we look at the default scope visibility.
The Default Modifier
When we do not apply any of the modifiers (private, protected, or public) to an entity, it gets the default visibility. An entity defined with a default visibility will be accessible within the class defining it and to all the classes that belong to the same package, but it is not accessible to any class in a different package.
To understand the visibility rules for a default modifier, remove the modifier in the declarations of the count and setCount members of MyClass of the previous post. The MyClass.java file compiles without errors, indicating that both DerivedClass and NonDerivedClass belonging to mypackage have access to these members. The NewClass.java file, however, will not compile, giving errors, on the statements shown in the following code:
package myanotherpackage;
import mypackage.MyClass;
class DerivedClass extends MyClass {
void someMethod() {
count = 10; // this does not compile
setCount(5); // this does not compile
}
}
class NonDerivedClass {
void someMethod(int count) {
MyClass obj = new MyClass();
obj.count = 10; // this does not compile
obj.setCount(5); // this does not compile
}
}
Thus, an identifier having default scope is accessible to any class within the same package and not to any other class belonging to another package.
Now that we have seen the various visibility criteria for the entities and understand Java packages, let’s look at the rules that must be applied when using inheritance.
A Few Rules on Inheriting
A member that is inherited in a subclass cannot have a weaker access privilege than the access privilege originally assigned to it. It can have only a stronger access privilege. The weakest type of access is private and the strongest is public. This rule applies only to the methods of a class and not to its fields.
A field with the same name declared in a subclass is treated as a shadowed variable in the subclass that essentially hides the corresponding declaration in the base class. This rule can be exemplified using the following cases:
· A method declared public in a superclass also must be public in all subclasses.
· A method declared protected in a superclass must either be protected or public in subclasses; it cannot be private nor have a default scope.
· A method declared without access control (no modifier was used) cannot be declared private in a subclass.
· A member declared private is not inherited at all, so there is no rule for it.
Hemant Patel
20-Apr-2017