Fields should be declared private unless there is a good
reason for not doing so.

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.

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.
*/publicfinalclass Planet {
public Planet (double aMass, String aName, Date aDateOfDiscovery) {
fMass = aMass;
fName = aName;
//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
fDateOfDiscovery = new Date(aDateOfDiscovery.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.
*/publicdouble getMass() {
return fMass;
}
/**
* 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 fName;
}
// /**
// * 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 fDate.
// */
// public Date getDateOfDiscovery() {
// return fDateOfDiscovery;
// }
/**
* 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() {
returnnew Date(fDateOfDiscovery.getTime());
}
// PRIVATE
/**
* Final primitive data is always immutable.
*/privatefinaldouble fMass;
/**
* An immutable object field. (String objects never change state.)
*/privatefinal String fName;
/**
* 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.)
*/privatefinal Date fDateOfDiscovery;
}

The above class uses a defensive copy as part of its design,
but there are cases in which defensive copies aren't desired. The point is that for mutable fields,
you need to know the difference, and make the appropriate choice.

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.