Page History

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 082008|AA. Java References#Bloch 08]\].

*EX1:* According to Sun's Code Conventions document \[[Conventions 092009|AA. Java References#Conventions 09]\]:

*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 082008|AA. Java References#Bloch 08]\]. This exception applies to both mutable as well as immutable fields.

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