From a design point of view, it is important to note that the Unified Modeling
Language (UML) offers three levels of visibility: public,
protected, and private, as indicated
in Table 1. For programmers, it is good to know that
the Java programming language supports
these three visibilities and adds a fourth: default. Table
1 describes each type of visibility supported by the Java programming language, indicating the
appropriate UML symbol, the Java keyword that you would apply when declaring
a member function, a description of what each visibility means, and my
advice for applying each type of visibility effectively. Listing 1 depicts how to declare a member function in the UML; notice how the
visibility is indicated with the "+" symbol. Listing 2 presents the declaration of that same member function in Java code; notice
the use of the keyword public in its signature.
My general rule of thumb is to be as restrictive as possible when setting the visibility of a method. In other words, if a method doesn't have to be public, then make it protected. If it doesn't have to be protected, then make it private. Finally, use default visibility only when you mean it and document your reasoning for applying that visibility in the method header documentation if it isn't clear why you applied it. You may need to refer to the tip Documenting Java member functions, in which we discussed member function documentation.
Table 1. Visibility of Java member functions| Visibility | UML symbol | Java keyword | Description | Suggested usage |
| Public | + | public | A public member function can be invoked by any other member function in any other object or class. | When the member function must be accessible by objects and classes outside of the class hierarchy in which the member function is defined. |
| Protected | # | protected | A protected member function can be invoked by any member function in the class in which it is defined or any subclasses of that class. | When the member function provides behavior that is needed internally within the class hierarchy but not externally. |
| Private | - | private | A private member function can only be invoked by other member functions in the class in which it is defined, but not in the subclasses. | When the member function provides behavior that is specific to the class. Private member functions are often the result of refactoring, also known as reorganizing, the behavior of other member functions within the class to encapsulate one specific behavior. |
| Default | No symbol available | No keyword, simply leave it blank | The member function is effectively public to all other classes within the same package, but private to classes external to the package. This is sometimes called package visibility or friendly visibility. | This is an interesting feature, but be careful with its use. I use it when I'm building domain components, collections of classes that implement a cohesive business concept such as "Customer", to restrict access to only the classes within the component/package. |
Listing 1. Declaration of the signature of a member function in the UML
+ hasParkingPrivileges(): boolean |
Listing 2. Declaration of a simple member function in Java code
public boolean hasParkingPrivileges()
{
return true;
} |
- 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 Ambler. New York: Cambridge University Press, 1998.
- The Object Primer 3rd 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: Addision-Wesley Longman, Inc., 1996.
- The Java FAQ by Jonni Kanerva. Reading, MA: Addision-Wesley Longman, Inc., 1997.
- 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.
Scott W. Ambler is President of Ronin International, a consulting firm specializing in object-oriented software process mentoring, architectural modeling, and Enterprise JavaBeans (EJB) development. He has authored or co-authored several books about object-oriented development, including the recently released The Object Primer 2nd Edition, which covers, in detail, the subjects summarized in this article. He can be reached at scott.ambler@ronin-intl.com and at his Web site at www.ambysoft.com.




