Table 1 describes the three types of field visibility, indicating the Unified Modeling Language (UML) symbols, the Java keywords, a description of what the visibility means, and my suggested proper usage for that visibility. As you can see, the rules and notations for field visibility are consistent with those for member function visibility, as discussed last week.

Table 1. Visibility of fields in Java programs

In my experience, all fields should be declared private for purposes of information hiding and encapsulation. When fields are declared protected, there is the possibility that methods in subclasses will directly access them, effectively increasing the coupling within a class hierarchy. This increased coupling makes your classes more difficult to maintain and enhance; therefore, it should be avoided.

To show you how to implement fields with different visibilities, I present the declarations for the fields of the Address class in Figure 1. It is possible to declare fields that are public or protected, as you can see in the source code example, but that is rarely a good idea.

/**
* The city street of the address
*
* @example 1701 Enterprise Way
*/
private String street;

/**
* The name of the city
*
* @example Metropolis
*/
protected String city;

/**
* The state/province that the address is in
*/
public State state;

/**
* The ZIP code that the address is in
*
* @example 90210
*/
private String zipCode;

Fields should never be accessed directly; instead, accessors should be used. Accessor methods come in two flavors: setters and getters (sometimes referred to as mutators and accessors, respectively). A setter modifies the value of a field, whereas a getter obtains its value. The only time that I would consider going against this rule is when the accessor methods are clearly impacting the performance of my application and I have no other alternative for improving the performance to an acceptable level -- even then I would attempt to minimize the number of fields that I access directly. By the way, I've been working in Java technology since the autumn of 1995 and have yet to break this rule. At the same time, I've lost track of the number of developers I've met who complain about accessor method performance.

An essential concept that Java programmers must learn is that the only accessor methods that are allowed to work directly with a field are the accessors themselves. Yes, it is possible to directly access a private field within the methods of the class in which the field is defined, but you don't want to do so because you would increase the coupling within your class. In fact, the use of accessors is a practice that is enforced in Enterprise JavaBean (EJB) 2.0 environments for all persistent fields. The effective use of accessor methods will be covered in future tips.

Resources

• The earlier tip on "Member function visibility in Java programs."
  
  
• Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology by Scott W. Ambler. New York: Cambridge University Press, 1998.
  
  
• Process Patterns -- Building Large-Scale Systems Using Object Technology by Scott W. Ambler. New York: Cambridge University Press, 1998.
  
  
• The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2000.
  
  
• The Unified Process Construction Phase by Scott W. Ambler and Larry L. Constantine. Gilroy, CA: R&D Books, 2000.
  
  
• The Java Language Specification by James Gosling, Bill Joy, and Guy Steele. Reading, MA: Addison-Wesley Longman, Inc., 1996.
  
  
• Object-Oriented Software Construction, Second Edition by Bertrand Meyer. Upper Saddle River, NJ: Prentice-Hall PTR, 1997.
  
  
• The Elements of Java Style by Alan Vermeulen, Scott W. Ambler, Greg Bumgardner, Eldon Metz, Trevor Misfeldt, Jim Shur, and Patrick Thompson. New York: Cambridge University Press, 2000.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Resources
• About the author
• Comments