Section 10.2. The Call Stack

10.2 The Call Stack

As you step in and out of methods , the Call Stack window will keep track of the order and hierarchy of method calls. If you look back at Figure 10-2, you'll see the Call Stack window in the lower righthand corner of the application. Figure 10-12 shows a close-up picture of the Call Stack window. You can see that the Time constructor was called by the Run( ) method, while the Run( ) method was in turn called by Main( ).

Figure 10-12. The call stack

In this case, if you double-click on the second line in the Call Stack window, the debugger will show you the line in Run( ) that called the Time constructor, as shown in Figure 10-13.

Figure 10-13. Tracing the call stack

Chapter 11. Inheritance and Polymorphism

In Chapter 8, you learned how to create new types by declaring classes, and in Chapter 3, you saw a discussion of the principle object relationships of association, aggregation, and specialization. This chapter focuses on specialization , which is implemented in VB.NET through inheritance . This chapter also explains how instances of more specialized classes can be treated as if they were instances of more general classes, a process known as polymorphism . This chapter ends with a consideration of not inheritable classes , which cannot be specialized, and a discussion of the root of all classes, the Object class.

11.1 Specialization and Generalization

Classes and their instances (objects) do not exist in a vacuum but rather in a network of interdependencies and relationships, just as we, as social animals, live in a world of relationships and categories. One of the most important relationships among objects in the real world is specialization , which can be described as an is-a relationship. When we say that a Dog is-a mammal, we mean that the dog is a specialized kind of mammal. It has all the characteristics of any mammal (it bears live young, nurses with milk, has hair), but it specializes these characteristics to the familiar characteristics of canine domesticus . A Cat is also a mammal. As such we expect it to share certain characteristics with the dog that are generalized in Mammal, but to differ in those characteristics that are specialized in Cat.

The specialization and generalization relationships are both reciprocal and hierarchical. They are reciprocal because specialization is the obverse side of the generalization coin. Thus, Dog and Cat specialize Mammal, and Mammal generalizes from Dog and Cat.

These relationships are hierarchical because they create a relationship tree, with specialized types branching off from more generalized types. As you move up the hierarchy you achieve greater generalization . You move up toward Mammal to generalize that Dogs and Cats and Horses all bear live young. As you move down the hierarchy, you specialize. Thus, the Cat specializes Mammal in having claws (a characteristic) and purring (a behavior).

Similarly, when you say that ListBox and Button are Windows, you indicate that you expect to find characteristics and behaviors of Windows in both of these types. In other words, Window generalizes the shared characteristics of both ListBox and Button, while each specializes its own particular characteristics and behaviors.

The Unified Modeling Language (UML) is a standardized "language" for describing an object-oriented system. In the UML, classes are represented as boxes. The name of the class appears at the top of the box, and ( optionally ) methods and members can be listed in the sections within the box.

In the UML, you model specialization relationships as shown in Figure 11-1. Note that the arrow points from the more specialized class up to the more general class. In the figure, the more specialized Button and ListBox classes point up to the more general Window class.

Figure 11-1. An is-a relationship

It is not uncommon for two classes share functionality. When this occurs, you can factor out these commonalities into a shared base class, which is more general than the more specialized classes. This provides you with greater reuse of common code, and with code that is easier to maintain.

For example, suppose you started out creating a series of objects as illustrated in Figure 11-2.

Figure 11-2. Objects deriving from Window

After working with RadioButtons, CheckBoxes, and Command buttons for a while, you realize that they share certain characteristics and behaviors that are more specialized than Window but more general than any of the three. You might factor these common traits and behaviors into a common base class, Button, and rearrange your inheritance hierarchy as shown in Figure 11-3. This is an example of how generalization is used in object-oriented development.

Figure 11-3. Factoring a Button class

The UML diagram in Figure 11-3 depicts the relationship among the factored classes and shows that both ListBox and Button derive from Window, and that Button is in turn specialized into CheckBox and Command. Finally, RadioButton derives from CheckBox. You can thus say that RadioButton is a CheckBox, which in turn is a Button, and that Buttons are Windows.

This is not the only, or even necessarily the best, organization for these objects, but it is a reasonable starting point for understanding how these types (classes) relate to one another.

Actually, although this might reflect how some widget hierarchies are organized, I am very skeptical of any system in which the model does not reflect how I perceive reality, and when I find myself saying that a RadioButton is a CheckBox, I have to think long and hard about whether that makes sense. I suppose a RadioButton is a kind of checkbox. It is a checkbox that supports the idiom of mutually exclusive choices. That said, it is a bit of a stretch and might be a sign of a shaky design.