...
| Code Block |
|---|
|
public static final HashMap<IntegerHashMap<Integer, String>String> hm = new HashMap<IntegerHashMap<Integer, String>String>();
|
Compliant Solution
Mutable data members that are static must always be declared private.
| Code Block |
|---|
|
private static final HashMap<IntegerHashMap<Integer, String>String> hm = new HashMap<IntegerHashMap<Integer, String>String>();
|
Exceptions
| Wiki Markup |
|---|
*EX1:* According to Sun's Code Conventions document \[[Conventions 09|AA. Java References#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.
| Wiki Markup |
|---|
*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 08|AA. Java References#Bloch 08]\]. This exception applies to both mutable as well as immutable fields. |
...
08. Object Orientation (OBJ) 08. Object Orientation (OBJ) OBJ01-J. Understand how a superclass can affect a subclass
