External Scope CECS 277 Mimi Opkins

External Scope Access Rules Java allows class variable/methods to be accessed from three external places: derived classes, variable/methods of the same package, and code external to the package.

Packages A package contains a set of related classes, and sometimes we want to make variable/methods of those classes accessible to each other, even if they aren’t public. For example, suppose that a Date class is part of a calendar package. Another class, called ShowWeek, in the same package displays a week surrounding a given date. Both of the classes use the Julian day as their internal representation. It is more efficient for a Date object to make its Julian day variable/method directly accessible to ShowWeek than to require conversion of the date first to its external form and then back to a Julian day in the other object. The user is unaware of this shortcut, so the encapsulation is preserved.

Access Levels Classes naturally belong together in a package if they have common internal representations. In that case, they can bypass each other’s encapsulations because the common details of their implementations are already known to anyone who’s working with them. Java defines four levels of access for class variable/methods, three of which enable direct access by other package variable/methods. The four levels of access are public protected default (package) private There are keywords that we use as access modifiers for each of these levels except the package level, which is the default level. If you omit an access modifier from the declaration of a class variable/method, it is at the package level of access by default.

Public Access A public variable/method can be accessed from anywhere outside of the class. User code, derived classes, and other classes in the same package can all access a public variable/method. The variable/method may still be hidden by a declaration of the same name in another class, in which case references to it must be qualified with its class or instance name. Here’s an example of using qualified names. If the class ShowWeek defines a julianDay field and Date also defines julianDay as a static field, then ShowWeek would need to refer to Date.julianDay to access the static field of Date. If julianDay is an instance field of Date and the particular object is called instanceName, then ShowWeek must refer to it as follows: instanceName.julianDay

Protected Access A protected variable/method is accessible to classes in the same package and can be inherited by derived classes outside of the package. Code that is outside of the package can only inherit protected variable/methods of a class; it can’t access them directly. In the following code segment, we define two packages. The second package has a class (DerivedClass) that is derived from the class in the first package (SomeClass). DerivedClass inherits the protected field someInt from SomeClass. Notice that DerivedClass doesn’t include a declaration of someInt. DerivedClass defines a method that has one parameter of the class SomeClass and another parameter of its own class. It then tries to access the someInt field in both parameters.

package one; public class SomeClass { protected int someInt; }

import one.*; package two; public class DerivedClass extends SomeClass { void demoMethod(SomeClass param1, DerivedClass param2) param1.someInt = 1; // Generates a compiler error // Can't access variable/method of instance of SomeClass param2.someInt = 1; // This access is legal // It refers to the inherited variable/method }

The compiler will issue an error message for the first assignment statement because it is illegal to access the protected field of a superclass when the superclass resides in a different package. The second assignment is valid because it refers to the inherited field within DerivedClass. The protected modifier provides the least restrictive level of access that isn’t public. We use protected to enable users to extend our class with a subclass. The subclass inherits its own copies of the protected variable/methods, but cannot access the originals. If a package of classes is independent of an application (such as the java.util package), it is often desirable to enable users to derive their own classes from the library classes.

Package Access When no access modifier is specified, then classes in the same package can access the variable/method. No other external access is allowed. A variable/method at the package level of access cannot be inherited by a derived class in another package. Up to this point, we’ve given only examples in which every variable/method of a class is inherited by a subclass. With the introduction of the package level of access, we see that Java also lets us selectively restrict the variable/methods that are inherited. A derived class in the same package retains access to the variable/methods of its superclass that are at the package level of access. All classes within the same package have access to each other’s public, protected, and package variable/methods. Here’s the preceding example, but with both classes in the same package and someInt at the package level of access. In this case, both assignment statements are valid.

package one; public class SomeClass { int someInt; } public class DerivedClass extends SomeClass void demoMethod(SomeClass param1, DerivedClass param2) param1.someInt = 1; param2.someInt = 1;

Private Access Lastly, the private modifier cuts off all external access, even by classes in the same package. A private variable/method of a class can be referred to only by other variable/methods of the class, and only the internal scope rules apply to it. It isn’t even permissible for a derived class in the same package to access a private variable/method of its superclass. Instances of a class can refer to each other’s private variable/methods. A variable/method is private to its class, which includes all instances of the class. Thus two objects, someObj and otherObj, that have private int fields called someInt can refer to each other’s fields. That is, someObj can refer to otherObj.someInt and otherObj can refer to someObj.someInt. Within a method, all local identifiers are automatically private; Java doesn’t allow us to declare them with access modifiers. The reason is that the lifetime of a local identifier is limited to a particular method call, so it simply doesn’t exist when external code is running.

So far, we have primarily used the public and package levels of access, keeping data variable/methods at the package level and making most methods and classes public. This simple scheme provides encapsulation and a consistent user interface that is strictly a set of method calls. However, this scheme is inflexible and limits our ability to provide for either extension or the construction of related classes that are grouped into a package.

Which access modifier do I use? Now that we have a better understanding of Java’s access rules, we must consider which access modifier is most appropriate for each variable/method of a class. Once you have identified all of its variable/methods, take a second look at each one and ask the following question: Do I want to access this variable/method from other classes in the same package, from derived classes, or from user code? Based on your answer to each part of this question, use the table below to decide which access modifier is most appropriate. External Access public protected default (package) private Same package Yes No Derive class in another package Yes (inheritance only) User code