External Scope CECS 277 Mimi Opkins External Scope

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 and of the same package, 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 Show. Week, 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 Show. Week 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 Show. Week defines a julian. Day field and Date also defines julian. Day as a static field, then Show. Week would need to refer to Date. julian. Day to access the static field of Date. If julian. Day is an instance field of Date and the particular object is called instance. Name, then Show. Week must refer to it as follows: instance. Name. julian. Day

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 (Derived. Class) that is derived from the class in the first package (Some. Class). Derived. Class inherits the protected field some. Int from Some. Class. Notice that Derived. Class doesn’t include a declaration of some. Int. Derived. Class defines a method that has one parameter of the class Some. Class and another parameter of its own class. It then tries to access the some. Int field in both parameters.

package one; public class Some. Class { protected int some. Int; }

import one. *; package two; public class Derived. Class extends Some. Class { void demo. Method(Some. Class param 1, Derived. Class param 2) { param 1. some. Int = 1; // Generates a compiler error // Can't access variable/method of instance of Some. Class param 2. some. Int = 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 Derived. Class. 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 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 some. Int at the package level of access. In this case, both assignment statements are valid.

package one; public class Some. Class { int some. Int; } package one; public class Derived. Class extends Some. Class { void demo. Method(Some. Class param 1, Derived. Class param 2) { param 1. some. Int = 1; param 2. some. Int = 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, some. Obj and other. Obj, that have private int fields called some. Int can refer to each other’s fields. That is, some. Obj can refer to other. Obj. some. Int and other. Obj can refer to some. Obj. some. Int. 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 Yes No Derive class in another package Yes (inheritance only) No No User code Yes No No No