When data members are declared public or protected, it is difficult to control how they are accessed. Malicious callers can manipulate such members in unintended 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 (e.g., by defensive copying, validating input, logging and so on). The wrapper methods must preserve the invariants of the class at all times.

Noncompliant Code Example (Public Primitive Field)

In this noncompliant code example, the data member total keeps track of the total number of elements as they are added and removed from a container using the methods add() and remove(), respectively.

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, as a {{public}} data member, {{total}} can be altered by external code, independent of these actions. This noncompliant code example violates the condition that {{public}} classes must not expose data members by declaring them {{public}}. It is a bad practice to expose both mutable as well as immutable fields from a {{public}} class \[[Bloch 2008|AA. Bibliography#Bloch 08]\].

Compliant Solution (Provide Wrappers and Reduce Accessibility of Primitive Members)

This compliant solution declares total as private and provides a public accessor so that the required member can be accessed beyond the current package. The add() and remove() methods modify its value without violating any class invariants.

public class Widget {
  private int total; // Declared private

  void add() {
    // ...
  }

  void remove() {
    // ...
  }

  public int getTotal () {
    return total;
  }
}

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

Noncompliant Code Example (Public Mutable Field)

This noncompliant code example shows a static mutable hash map with public accessibility.

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

Compliant Solution (Provide Wrappers and Reduce Accessibility of Mutable Members)

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);
}

Depending on the required functionality, wrapper methods may be used to retrieve an instance of the Hashmap or a contained value. This compliant solution adds a wrapper method to return the value of an element given its index in the Hashmap.

Exceptions

*OBJ00-EX1:* 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-EX2:* "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 as well as immutable fields.

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

Risk Assessment

Failing to declare data members private can break encapsulation.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Other Languages

This guideline appears in the C++ Secure Coding Standard as OOP00-CPP. Declare data members private.

Bibliography

\[[JLS 2006|AA. Bibliography#JLS 06]\] Section 6.6, Access Control
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 3-2 Define wrapper methods around modifiable internal state
\[[Long 2005|AA. Bibliography#Long 05]\] Section 2.2, Public Fields
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Items 13: Minimize the accessibility of classes and members; 14: In public classes, use accessor methods, not public fields

08. Object Orientation (OBJ)      08. Object Orientation (OBJ)      OBJ01-J. Be aware that a final reference may not always refer to immutable data