Page History

When It is difficult to control how data members are declared public or protected, it is difficult to control how they are accessed. Attackers can manipulate such members in unintended unexpected ways. Use wrapper accessor methods to expose class members beyond the package in which their class is declared. The use of wrapper methods enables appropriate monitoring and control of the modification of data members (for example, by defensive copying, validating input, and logging). The wrapper methods must can preserve the invariants of the class at all timesclass invariants.

Noncompliant Code Example (Public Primitive Field)

...

public class Widget {
  public int total; // Number of elements

  void add() {
    if (total < Integer.MAX_VALUE) {      
      total++;
      // ...
    } else {
      throw new ArithmeticException("Overflow");
    }
  }

  void remove() {  
    if (total > Integer.MIN_VALUE) {      
      total--;
      // ...
    } else {
      throw new ArithmeticException("Overflow");
    }
  }
}

However, asAs a {{public}} data member, {{total}} can be altered by external code, independent of these actions the {{add()}} and {{remove()}} methods. It is a bad practice to expose both mutable and immutable fields from a {{public}} class \[[Bloch 2008|AA. Bibliography#Bloch 08]\].

...

It is good practice to use wrapper methods, such as add(), remove(), and getTotal(), to manipulate the private internal state because the methods can perform additional functions, such as input validation and security manager checks, prior to manipulating the state.

...

Mutable data members that are static must always be declared private.

private static final HashMap<Integer, String> hm = new HashMap<Integer, String>();

public static String getElement(int key) { 
  return hm.get(key);
}

...

Exceptions

*OBJ00-EX1EX0:* According to Sun's Code Conventions document \[[Conventions 2009|AA. Bibliography#Conventions 09]\]

One example of appropriate public instance variables is the case where the class is essentially a data structure, with no behavior. In other words, if you would have used a struct instead of a class (if Java supported struct), then it's appropriate to make the class's instance variables public.

*OBJ00-EX2EX1:* "if a class is package-private or is a {{private}} nested class, there is nothing inherently wrong with exposing its data fields—assuming they do an adequate job of describing the abstraction provided by the class. This approach generates less visual clutter than the accessor-method approach, both in the class definition and in the client code that uses it" \[[Bloch 2008|AA. Bibliography#Bloch 08]\]. This exception applies to both mutable and immutable fields.

OBJ00-EX3EX2: Static final fields that contain values of mathematical constants may be declared public.

...