10.5 Visibility


Visibility in the UML refers to accessibility of internal object elements by other objects. Visibility is always a design concern. There are four general guidelines of visibility:

  1. If clients need it, make it visible, otherwise make it inaccessible. This first guideline is pretty obvious. Once you are down in the depths of detailed design, you should have a pretty good idea which messages are being sent to an object. If other clients are depending on the service, then they must be able to call it. This is none other than the old data-hiding principle in vogue since the 1970s.

  2. Only make semantically appropriate operations visible. This guideline seeks to avoid pathological coupling among classes. For example, suppose a class is using a container class. Should the operations be GetLeft() and GetRight() or Prev() and Next()? The first pair makes the implementation visible (binary tree) while the latter pair captures the essential semantics (ordered list).

  3. Attributes should never be directly visible to clients. This guideline is similar to the previous one in that it wants to avoid tight coupling whenever possible. If clients have direct access to attributes, they fundamentally depend on the structure of that attribute. Should the structure change, the clients all become instantly broken and must be modified as well. Additionally, accessor and mutator operations applied to that attribute can ensure that preconditions are met, such as valid ranges or consistency with other class attributes. Direct access to the attribute circumvents these safeguards. The "Hungarian" naming convention uses the type of the variable or attribute in the name. I recommend that this highly questionable practice be avoided precisely because it introduces an artificial and unnecessary tight coupling attribute and its type.

  4. When different levels of visibility are required to support various levels of coupling, use the interface pattern to provide the sets of interfaces. Sometimes a class must present different levels of access to different clients. When this is true, the interface pattern is an obvious solution. A class can have many interfaces, each semantically appropriate to its clients.

The UML provides a simple, if peculiar, syntax for specifying visibility on the class diagram: A visibility attribute is prepended to the class member. The UML defines the following visibility attributes:

#

Private accessible only within the class itself

Protected accessible only by the class and its subclasses

+

Public generally accessible by other classes

~

Package accessible to other member of the same package

Some theorists are adamant that attributes should be private (as opposed to protected) and even subclasses should go through accessor methods to manipulate them. Personally, I find that view somewhat draconian because subclasses are already tightly coupled with their superclasses, but to each his or her own.

Another approach to providing different levels of access is through the use of friend classes.[7] Friend classes are often used as iterators in the container pattern, discussed in Chapter 9. Another use is the facilitation of unit testing by making unit testing objects friends of the class under test.

[7] The use of friend classes results in a kind of "clothing-optional" design, which, although it can be fun, may make some designers nervous.



Real Time UML. Advances in The UML for Real-Time Systems
Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition)
ISBN: 0321160762
EAN: 2147483647
Year: 2003
Pages: 127

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