March 8, 2011, 8:40 p.m.
posted by demx
Static Parts of Your Classes
In UML, operations, attributes, and even classes themselves can be declared static. To help us understand what static means, we need to look at the lifetime of regular non-static class members. First, lets take another look at the BlogAccount class from earlier on in this chapter, shown in Figure.
The BlogAccount class is made up of three regular attributes and one regular operation
Because each of the attributes and operations on the BlogAccount class are non-static, they are associated with instances, or objects, of the class. This means that each object of the BlogAccount class will get their own copy of the attributes and operations, as shown in Figure.
Both account1 and account2 contain and exhibit their own copy of all the regular non-static attributes and operations declared on the BlogAccount class
Sometimes you want all of the objects in a particular class to share the same copy of an attribute or operation. When this happens, a class's attributes and operations are associated with the class itself and have a lifetime beyond that of the any objects that are instantiated from the class. This is where static attributes and operations become useful.
For example (and let's ignore the possibility of multiple classloaders for now), if we wanted to keep a count of all the BlogAccount objects currently alive in the system, then this counter would be a good candidate for being a static class attribute. Rather than the counter attribute being associated with any one object, it is associated with the BlogAccount class and is therefore a static attribute, as shown in Figure.
The accountCounter attribute needs to be incremented every time a new BlogAccount is created. The accountCounter attribute is declared static because the same copy needs to be shared between all of the instances of the BlogAccount class. The instances can increment it when they are created and decrement it when they are destroyed, as shown in Figure.
An attribute or operation is made static in UML by underlining it; the accountCounter attribute will be used to keep a running count of the number of objects created from the BlogAccount class
The static accountController attribute is shared between the different BlogAccount objects to keep a count of the currently active BlogAccount objects within the system
If the accountCounter attribute were not static, then every BlogAccount instance would get its own copy of the accountCounter attribute. This would not be very useful at all since each BlogAccount object would update only its own copy of accountCounter rather than contributing to a master object instance counterin fact, if accountCounter were not static, then every object would simply increment its own copy to 1 and then decrement it to 0 when it is destroyed, which is not very useful at all!