Section 4.3. Visibility


4.3. Visibility

How does a class selectively reveal its operations and data to other classes? By using visibility. Once visibility characteristics are applied, you can control access to attributes, operations, and even entire classes to effectively enforce encapsulation. See "Encapsulation" earlier in this chapter for more information on why encapsulation is such a useful aspect of object-oriented system design.

There are four different types of visibility that can be applied to the elements of a UML model, as shown in Figure 4-6. Typically these visibility characteristics will be used to control access to both attributes, operations, and sometimes even classes (see the "Packages" section in Chapter 13 for more information on class visibility).

Figure 4-6. UML's four different visibility classifications


4.3.1. Public Visibility

Starting with the most accessible of visibility characteristics, public visibility is specified using the plus (+) symbol before the associated attribute or operation (see Figure 4-7). Declare an attribute or operation public if you want it to be accessible directly by any other class.

Figure 4-7. Using public visibility, any class within the model can access the publicURL attribute


The collection of attributes and operations that are declared public on a class create that class's public interface. The public interface of a class consists of the attributes and operations that can be accessed and used by other classes. This means the public interface is the part of your class that other classes will depend on the most. It is important that the public interface to your classes changes as little as possible to prevent unnecessary changes wherever your class is used.

Public Attributes

To have public attributes or to not have public attributes? That is the question. Many object-oriented designers groan at the use of public attributes: opening a class's attributes to the rest of the system is like exposing your house to any person off the street without requiring him to check with you before entering. There is just as much potential for abuse.

It's usually best to avoid public attributes, but there are always exceptions to the rule. One example where it is generally accepted to use a public attribute is when the attribute is a constant that may be used by a number of different classes. Attributes that act as constants, i.e., to be given an initial unchangeable value are given the property of readOnly (see "Attribute Properties"). In this situation, exposing the attribute to the rest of your system is not quite so dangerous since its value cannot be changed.


4.3.2. Protected Visibility

Protected attributes and operations are specified using the hash (#) symbol and are more visible to the rest of your system than private attributes and operations, but are less visible than public. Declared protected elements on classes can be accessed by methods that are part of your class and also by methods that are declared on any class that inherits from your class. Protected elements cannot be accessed by a class that does not inherit from your class whether it's in the same package or not, as shown in Figure 4-8. See Chapter 5 for more information on inheritance relationships between classes.

Protected visibility is crucial if you want allow specialized classes to access an attribute or operation in the base class without opening that attribute or operation to the entire system. Using protected visibility is like saying, "This attribute or operation is useful inside my class and classes extending my class, but no one else should be using it."

Java confuses the matter a little further by allowing access to protected parts of a class to any other class in the same package. This is like combining the accessibility of protected and package visibility, which is covered in the next section.


Figure 4-8. Any methods in the BlogAccount class or classes that inherit from the BlogAccount class can access the protected creationDate attribute


4.3.3. Package Visibility

Package visibility, specified with a tilde (~), when applied to attributes and operations, sits in between protected and private. As you'd expect, packages are the key factor in determining which classes can see an attribute or operation that is declared with package visibility .

The rule is fairly simple: if you add an attribute or operation that is declared with package visibility to your class, then any class in the same package can directly access that attribute or operation, as shown in Figure 4-9. Classes outside the package cannot access protected attributes or operations even if it's an inheriting class.In practice, package visibility is most useful when you want to declare a collection of methods and attributes across your classes that can only be used within your package.

For example, if you were designing a package of utility classes and wanted to reuse behavior between those classes, but not expose the rest of the system to that behavior, then you would declare package visibility to those particular operations internally to the package. Any functionality of utility classes that you wanted to expose to the rest of the application could then be declared with public visibility.

See "Package Diagrams" in Chapter 13 for more on how packages control visibility of elements such as classes.

Figure 4-9. The countEntries operation can be called by any class in the same package as the BlogAccount class or by methods within the BlogAccount class itself


4.3.4. Private Visibility

Last in line in the UML visibility scale is private visibility . Private visibility is the most tightly constrained type of visibility classification, and it is shown by adding a minus (-) symbol before the attribute or operation. Only the class that contains the private element can see or work with the data stored in a private attribute or make a call to a private operation, as shown in Figure 4-10.

Private visibility is most useful if you have an attribute or operation that you want no other part of the system to depend on. This might be the case if you intend to change an attribute or operation at a later time but don't want other classes with access to that element to be changed.

It's a commonly accepted rule of thumb that attributes should always be private and only in extreme cases opened to direct access by using something more visible. The exception to this rule is when you need to share your class's attribute with classes that inherit from your class. In this case, it is common to use protected. In well-designed OO systems, attributes are usually private or protected, but very rarely public.


Figure 4-10. aMethod is part of the BlogAccount class, so it can access the private name attribute; no other class's methods can see the name attribute





Learning UML 2.0
Learning UML 2.0
ISBN: 0596009828
EAN: 2147483647
Year: 2007
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net