Defining Visibility

---

If you really get to be friendly and know your classes well, you’ll be able learn some private secrets about them. When you make your models and design your classes, you’ll be able to define what’s visible and what’s not. Typically, all the attributes are private so that only the owning object can see the values of the attributes. Thus, each person object can see his or her own age, because you own and control your own attributes.

Each attribute—and each operation—of a class should have its visibility determined. You model the visibility by preceding the feature definition with a typographical symbol, as defined in Table 3-6.

Table 3-6: Symbols for Modeling Visibility

Symbol	Visibility	Meaning
+	Public	Any object can use the feature.
-	Private	Only the owning object can use this feature.
#	Protected	Only the owning object or descendants of the owning object can use this feature.
~	Package	Only objects in the same package as the owning object’s package can use this feature.

The object-oriented principle of information hiding should be guiding you to avoid exposing any details. Keeping the details hidden allow you to change them later, whenever you want to. To give yourself this freedom to change, make all the attributes private. You don’t want anyone to get to them without going through the accessor (GET/SET) operations where you can control the access.

On the other hand, most operations are public. You want the objects to be useful, so they need to be accessible to be told do their stuff.

You can find more details on information hiding and other principles of object orientation in the Chapter 2.

Marking attributes as public and private

 Technical Stuff   Many UML tools enforce the information-hiding concept of attribute privacy strictly. Even if you mark an attribute as public, it is still generated as private. How do the UML tools get away with ignoring your requests, after all, you’re the modeler and should be in charge?

Most tools generate the attribute as private, but generate accessor operations with your requested visibility. This surprising trick puts up a wall that enables you to control the details of the access.

If you modeled it as +name:String, you’ll probably automatically have the following generated:

 - name:String + getName():String + setName(toNewName:String) 

But what should you do, if you really want to have an attribute that’s mostly private, but not to everybody? In many programming languages, it’s possible to mark some classes as friends. Only close friends can get to see the private parts; these friends can break the encapsulation rules. (For more about encapsulation see Chapter 2.)

Marking static attributes

Every object in a class has its own attributes and keeps track of its own data. Sometimes, however, members of the same family have to share information. They do this through by flagging the attributes representing the shared information as static attributes. This indicates that the attribute has class-scope. Once flagged, every object in the class has the same value for that attribute. Change it once, and every object’s value is changed. You mark these attributes as static by underlining them. Operations that set or get these static attributes should also be marked static.

Normally, when a regular (non-static) operation is called or an attribute is referenced, you start with the object name, as follows:

• aCrashDummy.name indicates the name of the aCrashDummy object.

• myNeighbor.borrowTool() indicates the borrowTool operation on the myNeighbor object

With a static attribute, you refer to the class as a whole—so you precede the operations and attributes with the class name, like this:

• CrashDummy.nextID indicates the nextID used by the whole CrashDummy class

• CrashDummy.getNextID() also indicates the operation to get the nextID value used by the whole CrashDummy class

If you want to define a static attribute or operation for a class, include it in the class box, but flag it as static by underlining it. Figure 3-6 shows an example.

Figure 3-6: A class with many features.

The CrashDummy class in Figure 3-6 illustrates some of the features that are discussed in this chapter. The attribute compartment has several private attributes and the operation compartment has several public operations:

• The birth attribute captures the construction date for the Crash Dummy.

• The age attribute captures the targeted age that CrashDummy mimics.

• You use the gender attribute of the dummy to capture the gender that the CrashDummy mimics.

• Use the weight and height to capture physical properties of the dummy. Each has their own default value and a constraint governing their values.

• You can see a Boolean isWorking attribute, which reflects whether the dummy is need of repair.

• The nextID attribute is a static (also known as a class-scope) attribute, whose value is available to the class as a whole.

• The nextID attribute is used with the static operation getNextID().

• The CrashDummy() operation is also considered a static operation; although it makes a CrashDummy object, it operates on the class to do so.

• The CrashDummy() operation is also flagged with the stereotype «constructor» to remind the reader or tools that this operation will make up new objects.

Most of these attributes capture constant properties of a CrashDummy object. After you set them, you can forget them, as they don’t change over the life of the object. However, make you shouldn’t forget that objects typically have attributes that reflect the state of the object and may change over time.

---