One of the guiding principles of lasting value in programming is "Minimize ripple effects by keeping secrets." When a field is private, the caller cannot usually get inappropriate direct access to the field.

To clarify, there are three possibilities for a private field:

• primitive data such as int, boolean, and so on.
• immutable objects such as String and BigDecimal, whose data never changes.
• mutable objects, whose data can change (that is, they can change state). These need special care, and often need a defensive copy. It's easy to forget this. You should always remember that mutable object fields are 'hot spots' in your code, and need special care.

It's only the last case - the mutable object private field - where inappropriate direct access to a private field is possible. Here's an illustration:

Example 1

import java.util.Date;

/**
* Planet is an immutable class, since there is no way to change
* its state after construction.
*/
public final class Planet {

  public Planet (double mass, String name, Date dateOfDiscovery) {
     this.mass = mass;
     this.name = name;
     //make a private copy of aDateOfDiscovery
     //this is the only way to keep the fDateOfDiscovery
     //field private, and shields this class from any changes that 
     //the caller may make to the original aDateOfDiscovery object
     this.dateOfDiscovery = new Date(dateOfDiscovery.getTime());
  }

  /**
  * Returns a primitive value.
  *
  * The caller can do whatever they want with the return value, without 
  * affecting the internals of this class. Why? Because this is a primitive 
  * value. The caller sees its "own" double that simply has the
  * same value as fMass.
  */
  public double getMass() {
    return mass;
  }

  /**
  * Returns an immutable object.
  *
  * The caller gets a direct reference to the internal field. But this is not 
  * dangerous, since String is immutable and cannot be changed.
  */
  public String getName() {
    return name;
  }

//  /**
//  * Returns a mutable object - likely bad style.
//  *
//  * The caller gets a direct reference to the internal field. This is usually dangerous, 
//  * since the Date object state can be changed both by this class and its caller.
//  * That is, this class is no longer in complete control of dateOfDiscovery.
//  */
//  public Date getDateOfDiscovery() {
//    return dateOfDiscovery;
//  }

  /**
  * Returns a mutable object - good style.
  * 
  * Returns a defensive copy of the field.
  * The caller of this method can do anything they want with the
  * returned Date object, without affecting the internals of this
  * class in any way. Why? Because they do not have a reference to 
  * fDate. Rather, they are playing with a second Date that initially has the 
  * same data as fDate.
  */
  public Date getDateOfDiscovery() {
    return new Date(dateOfDiscovery.getTime());
  }

  // PRIVATE

  /**
  * Final primitive data is always immutable.
  */
  private final double mass;

  /**
  * An immutable object field. (String objects never change state.)
  */
  private final String name;

  /**
  * A mutable object field. In this case, the state of this mutable field
  * is to be changed only by this class. (In other cases, it makes perfect
  * sense to allow the state of a field to be changed outside the native
  * class; this is the case when a field acts as a "pointer" to an object
  * created elsewhere.)
  *
  * java.util.Date is used here only because its convenient for illustrating 
  * a point about mutable objects. In new code, you should use 
  * java.time classes, not java.util.Date.
  */
  private final Date dateOfDiscovery;
}
 

Example 2

This is a counter-example.

A common exception to this rule is that primitive constants and immutable objects can be declared as public static final fields. For example, see class for constants.