user-generated content: 

report abuse

What is visibility in Java?

In: Java Programming [Edit categories]
[Improve]
Visibility is another term used for Acess Specifiers for java variables and objects. 

One of the techniques in object-oriented programming is encapsulation. It concerns the hiding of data
in a class and making them available only through its methods. In this way the chance of making
accidental mistakes in changing values is minimized. Java allows you to control access to classes,
methods, and fields via so-called access specifiers. The access to classes, constructors, methods and
fields are regulated using access modifiers i.e. a class can control what information or data can be
accessible by other classes. To take advantage of encapsulation, you should minimize access
whenever possible. 

Java provides a number of access modifiers to help you set the level of access you want for classes as
well as the fields, methods and constructors in your classes. A member has package or default
accessibility when no accessibility modifier is specified. 

Access Modifiers

1. Private 
2. Protected 
3. Default 
4. Public 

Public is the most liberal access specifier and Private is the most restrictive access specifier.

Note: There are comments associated with this question. See the discussion page to add to the
conversation.

Question

What is the difference between public, private, and protected keywords? Do I even
need to use them?

Answer

We use these keywords to specify access levels for member variables, or for member
functions (methods).

 Public variables, are variables that are visible to all classes.

  Private variables, are variables that are visible only to the class to which they
belong.
 Protected variables, are variables that are visible only to the class to which
they belong, and any subclasses.

Deciding when to use private, protected, or public variables is sometimes tricky. You
need to think whether or not an external object (or program), actually needs direct
access to the information. If you do want other objects to access internal data, but
wish to control it, you would make it either private or protected, but provide functions
which can manipulate the data in a controlled way.

Take the following example :

public class bank_balance
{
public String owner;
public int balance;

public bank_balance( String name, int dollars )

{
owner = name;

if (dollars >= 0)
balance = dollars;
else
dollars =0;
}
}

We have declared our string and integer to be public. This means that any object in
the system can change the balance (setting it to zero, or even giving us a negative
balance). This could cause the program to fall over, even though we wrote code in our
constructor to prevent negative balances.

Instead, we should have provided a getBalance/setBalance method, and made our

balance private or proteced. Other objects can still access the data, but they can't put
invalid data in.
public class bank_balance
{
public String owner;
private int balance;

public bank_balance( String name, int dollars )

{
owner = name;

if (dollars >= 0)
 balance = dollars;
else
dollars =0;
}

public int getBalance()

{
return balance;
}

public void setBalance(int dollars)

{
if (dollars >= 0)
balance = dollars;
else
dollars = 0;
}
}

5.7 Variable and Method Visibility

One of the most important aspects of object-oriented design is data hiding,

or encapsulation. By treating an object in some respects as a "black box" and ignoring
the details of its implementation, we can write stronger, simpler code with
components that can be easily reused.

Basic Access Modifiers

By default, the variables and methods of a class are accessible to members of the class
itself and other classes in the same package. To borrow from C++ terminology,
classes in the same package arefriendly. We'll call this the default level of visibility.
As you'll see as we go on, the default visibility lies in the middle of the range of
restrictiveness that can be specified.

The modifiers public and private, on the other hand, define the extremes. As we

mentioned earlier, methods and variables declared as private are accessible only
within their class. At the other end of the spectrum, members declared as public are
always accessible, from any class in any package. Of course, the class that contains
the methods must also be public, as we just discussed. The public members of a class
should define its most general functionality--what the black box is supposed to
do. Figure 5.8 illustrates the three simplest levels of visibility.

Figure 5.8: Private, default, protected, and public visibility

Figure 5.8 continues with the example from the previous section. Public members
in TextArea are accessible from anywhere. Private members are not visible from
outside the class. The default visibility allows access by other classes in the package.

The protected modifier allows special access permissions for subclasses. Contrary to

how it might sound, protected is slightly less restrictive than the default level of
accessibility. In addition to the default access afforded classes in the same
package, protected members are visible to subclasses of the class, even if they are
defined in a different package. If you are a C++ programmer and so used to more
restrictive meanings for both the default and protected levels of access, this may rub
you the wrong way.

What was private protected?

Early on, the Java language allowed for certain combinations of modifiers, one of
which was private protected. The meaning of private protected was to limit visibility
strictly to subclasses (and remove package access). This was later deemed somewhat
inconsistent and overly complex and is no longer supported.[5]

[5] The meaning of the protected modifier changed in the Beta2 release of Java, and
the private protected combination appeared at the same time. They patched some
potential security holes, but confused many people.
Table 5.1 summarizes the levels of visibility available in Java; it runs generally from
most restrictive to least. Methods and variables are always visible within a class, so
the table doesn't address those:

Table 5.1: Visibility Modifiers

Modifier Visibility

private None

none (default) Classes in the package

protected Classes in package and subclasses inside or outside the package

public All classes

Subclasses and Visibility

There are two important (but unrelated) notes we need to add to the discussion of
visibility with regards to class members in subclasses. First, when you override
methods of a class in a subclass, it's not possible to reduce their visibility. While it is
possible to take a private method of a class and override it to be public in a subclass,
the reverse is not possible. This makes sense when you think about the fact that
subtypes have to be usable as instances of their supertype (e.g., a Mammal is a type
of Animal). If we could reduce the visibility of an overridden method, this would be a
problem. However, we can reduce the visibility of a variable because it simply results
in a shadowed variable. As with all shadowed variables, the two variables are distinct
and can have separate visibilities in their different class forms.

The second point is that protected variables of a class are visible to its subclasses, but
unlike C++, only in objects of the subclass's type or its subtypes. In other words, a
subclass can see aprotected variable from its superclass as an inherited variable, but it
can't access the variable in a separate instance of the superclass itself. This can be
confusing because often we forget that visibility modifiers don't resrtict between
multiple instances of the same class in the same way that they do instances of
different classes. Two instances of the same type of object can normally access all of
each other's members, including private ones. Said another way: two instances of Cat
can access all of each other's variables and methods (including private ones), but a Cat
can't access a protected member in an instance of Animal, unless it can prove that the
Animal is a Cat.
Packages and Compilation Interfaces
Units