Visibility Modifiers & Inheritance
[ Home ] [ Up ] [ What is Inheritance? ] [ Inheritance versus Containment ] [ Superclasses & Subclasses ] [ Visibility Modifiers & Inheritance ] [ Final Classes & Methods ] [ Polymorphism ] [ Data Hiding & Encapsulation ] [ Abstract Classes ] [ Interfaces ] [ Cloning Objects ] [ The Collections Framework ] [ Interfaces & Callbacks ]

 

 

An Update

Earlier, we talked about the visibility modifiers public and private. Now, with inheritance, we can talk about the third visibility modifier keyword:

protected

Here's an updated discussion, including this new protected modifier:

Visibility Modifiers

The keywords public and private and protected are visibility modifiers, which have the following effect:

A private member of a class is visible only in methods defined within that class.

A public member of a class is visible within the class where it is defined, and within all classes that are in the same package as that class.

If a member is declared with no visibility modifiers, then it has default package visibility, and is visible only within the class that defines it and within classes defined in the same package. (This is analogous to the friend concept in C++ -- all classes within a package are 'friendly' to each other.)

A protected member of a class is visible within the class where it is defined, and within all subclasses of that class, and also within all classes that are in the same package as that class.

To summarize:

Accessible to: Member Visibility
public protected package private
Same class yes yes yes yes
Class in same Package yes yes yes no
Subclass in different package yes yes no no
Non-subclass, different package yes no no no

Here are some simple rules to help you choose which visibility modifiers to use, when:

  • Use public only for methods and constants that form part of the public interface (sometimes called the API) of the class.
  • Use the default package visibility (a.k.a. "package private") for fields and methods that you want to be hidden from outside of the package, but to which you want cooperating ('friend') classes within the package to have access.
  • Use protected when you want to hide fields or methods from code that uses your class, but want those fields and methods to be fully accessible to code that extends your class.  
  • Use private for fields and methods that are only used inside the class and should be hidden from everywhere else. 
NOTE: It is very good practice to always make fields/data members within a class to be private.  I maintain that it is essential for good class design.  There is only one exception to this rule: 

When a field is part of the appropriate interface (API) for the class.  This should only be the case for static final fields (i.e. constants). Make such a static final field:

  • public, if it is part of the class's public interface
  • package private, if it is part of the class's contribution to the package's internal interface (i.e. used only by methods within that package)
  • protected, if it is part of the class's subclass interface (i.e. used only by methods within subclasses of that class)

My approach is to take the conservative approach:

  • Start out making all fields explicitly private.
  • Only change this decision, if you are absolutely convinced that the specified field is truly a part of your class's official interfaces (APIs)

Sometimes this involves some iteration during design, where you realize that some fields or methods should become non-private (this is rare for fields, but happens more often for methods as the design evolves).

 

This page was last modified on 02 October, 2007