Additional SideBars in
	An Introduction to Object-Oriented Programming (3nd Ed)
	by Timothy A. Budd
	(Last modified 16 October 1998)

As I re-read the book, I find places where I could have inserted side-boxes with additional information. Here are some of them.

Chapter 6, Page 133 -- Siblings and Private

A careful reader will note that the method canAttack is declared as private, and set the method findSolution requires one queen to invoke the canAttack method in its neighbor. How is this possible?

The answer requires a more careful examination of the meaning of private. Two queens are both instances of the same class. Does this mean they should be allowed to access each others private attributes? Most languages say yes; meaning that private is an attribute of a class, not an object. It is this feature that allows us to declare the canAttack method as private. A few languages, such as Smalltalk, answer no. The languages treat private as an attibute of objects, not of classes.

Chapter 11, Page 223 -- 8 Queens Revisited

Recall the 8 queens puzzle from Chapter 6. Some of the solutions presented there incorporated the idea of an active sentenel--a value that marked the end of the list of queens, and that responded to messages differently than the queens. The active sentenel was easy to do in the dynamically typed languages. I had two classes, Queen and SentenelQueen, and it just happened that the one at the end was a SentenelQueen, rather than a Queen. Since variables weren't typed, only values were, this little bit of magic was easy to slip by.

Why couldn't we do the same thing in C++ or Java? Well, those languages were strongly typed. Which meant that in THOSE languages I need to say what the type was associated with my neighbor. If I said my neighbor was a queen, then by golly it had better be a queen value, and nothing else.

BUT, with the introduction of the idea of polymorphic variables, I COULD have declared my neighbor to be a queen, and in fact the value could be a subclass of queen. So finally we see how dynamic sentienls could have been incorporated in the statically typed languages. I could indeed do the active sentinel trick in C++ in the 8-queens program, but only by making SentenelQueen a subclass of Queen, and overriding all the appropriate behavior. I didn't do that in the queens chapter because we hadn't discussed inheritance yet, and because for this to really work we also need (at least in C++) to discuss the keyword *virtual*, which is a topic for a later chapter.

Chapter 11, Page 232 -- Programmer Control over Method Binding

The designer of C++ touts the fact that the programmer has control over the binding of messages to methods as an advantage for the language. Methods that are not declared as virtual are bound statically, and thus have a slight execution-time advantage over methods that are virtual. On the other hand, in languages such as Smalltalk and Java (at least in the absence of optimizing compilers) such methods must always use a run-time method lookup.

The flip side, however, occurs when a method is not declared as virtual. Later another programmer may decide they want to create a subclass, and if the original parent class cannot be modified (it may, for example, be distributed only in binary) there is no way to accomodate the change. Thus the need to declare methods as virtual forces the C++ programmer to carefully consider they various ways in which a class may later be modified.

Chapter 19, Page 381 -- Different Paths to the Same Goal

Point out that the Java idea of Enumeration uses overriding, while the C++ concept of iterators uses overloading. Both are useful, and both solve roughly the same problem.

Chapter 21, Page 411 -- Trading Complexities

It is not unreasonable to ask whether the object-oriented version of the sorting procedure is any easier to understand than the conventional solution. It would not be surprizing to find that many people find the conventional solution simpler. This is because the conventional solution has everything in one place, rather than split over two different class hierarchies. (In an earlier chapter, we termed this the yo-yo problem.

It is vitally important, therefore, to understand what has been gained, and what has been lost. What has been gained is the ability to quickly and easily reuse the sorting framework in a new situation. What has been lost is the ability to easily understand the algorithm being used by the sorting procedure. But this difference is common to high level solutions in many different domains (civil engineering, electrical engineering). As one develops higher level abstractions, the details of the lower level abstractions become less and less important.