4.6. Static Parts of Your ClassesTo finish off this introduction to the fundamentals of class diagrams, let's take a look at one of the most confusing characteristics of classes: when a class operation or attribute is static . 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 4-21. Figure 4-21. The BlogAccount class is made up of three regular attributes and one regular operationBecause 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 4-22. Figure 4-22. Both account1 and account2 contain and exhibit their own copy of all the regular non-static attributes and operations declared on the BlogAccount classSometimes 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 4-23. 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 4-24. Figure 4-23. 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 classFigure 4-24. The static accountController attribute is shared between the different BlogAccount objects to keep a count of the currently active BlogAccount objects within the systemIf 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!
|