8 The run-time structure:objects In the previous chapter we saw that classes may have instances,called objects.We must now turn our attention to these objects and,more generally,to the run-time model of object-oriented computation. Where the previous chapters were mostly concemed with conceptual and structural issues,the present one will,for the first time in this book,include implementation aspects In particular it will describe how the execution of object-oriented software uses memory -a discussion continued by the study of garbage collection in the next chapter.As already noted,one of the benefits of object technology is to restore implementation issues to their full status;so even if your interest is mostly in analysis and design topics you should not be afraid of this excursion into implementation territory.It is impossible to understand the method unless you have some idea of its influence on run-time structures. The study of object structures in this chapter indeed provides a particularly good example of how wrong it is to separate implementation aspects from supposedly higher- level issues.Throughout the discussion,whenever we realize the need for a new O-O technique or mechanism,initially introduced for some implementation-related purpose, the real reason will almost always turn out to be deeper:we need the facility just as much for purely descriptive,abstract purposes.A typical example will be the distinction between references and expanded values,which might initially appear to be an obscure programming technique,but in reality provides a general answer to the question of sharing in whole-to-parts relations,an issue that figures prominently in many discussions of object-oriented analysis. This contribution of implementation is sometimes hard to accept for people who have been influenced by the view,still prevalent in the software literature,that all that counts is analysis.But it should not be so surprising.To develop software is to develop models.A good implementation technique is often a good modeling technique as well;it may be applicable,beyond software systems,to systems from various fields,natural and artificial. More than implementation in the strict sense of the term,then,the theme of this chapter is modeling:how to use object structures to construct realistic and useful operational descriptions of systems of many kinds
8 The run-time structure: objects In the previous chapter we saw that classes may have instances, called objects. We must now turn our attention to these objects and, more generally, to the run-time model of object-oriented computation. Where the previous chapters were mostly concerned with conceptual and structural issues, the present one will, for the first time in this book, include implementation aspects. In particular it will describe how the execution of object-oriented software uses memory — a discussion continued by the study of garbage collection in the next chapter. As already noted, one of the benefits of object technology is to restore implementation issues to their full status; so even if your interest is mostly in analysis and design topics you should not be afraid of this excursion into implementation territory. It is impossible to understand the method unless you have some idea of its influence on run-time structures. The study of object structures in this chapter indeed provides a particularly good example of how wrong it is to separate implementation aspects from supposedly higherlevel issues. Throughout the discussion, whenever we realize the need for a new O-O technique or mechanism, initially introduced for some implementation-related purpose, the real reason will almost always turn out to be deeper: we need the facility just as much for purely descriptive, abstract purposes. A typical example will be the distinction between references and expanded values, which might initially appear to be an obscure programming technique, but in reality provides a general answer to the question of sharing in whole-to-parts relations, an issue that figures prominently in many discussions of object-oriented analysis. This contribution of implementation is sometimes hard to accept for people who have been influenced by the view, still prevalent in the software literature, that all that counts is analysis. But it should not be so surprising. To develop software is to develop models. A good implementation technique is often a good modeling technique as well; it may be applicable, beyond software systems, to systems from various fields, natural and artificial. More than implementation in the strict sense of the term, then, the theme of this chapter is modeling: how to use object structures to construct realistic and useful operational descriptions of systems of many kinds
218 THE RUN-TIME STRUCTURE:OBJECTS $8.1 8.1 OBJECTS At any time during its execution,an O-O system will have created a certain number of objects.The run-time structure is the organization of these objects and of their relations. Let us explore its properties. What is an object? First we should recall what the word "object"means for this discussion.There is nothing The definition vague in this notion;a precise technical definition was given in the previous chapter: appeared on page 166.See also the Object rule,page Definition:object 171. An object is a run-time instance of some class. A software system that includes a class C may at various points of its execution create(through creation and cloning operations,whose details appear later in this chapter) instances of C;such an instance is a data structure built according to the pattern defined by C;for example an instance of the class PO/NT introduced in the previous chapter is a data structure consisting of two fields,associated with the two attributes x and y declared in the class.The instances of all possible classes constitute the set of objects. The above definition is the official one for object-oriented software.But "object" also has a more general meaning,coming from everyday language.Any software system is related to some external system,which may contain "objects":points,lines,angles, surfaces and solids in a graphics system:employees,pay checks and salary scales in a payroll system;and so on.Some of the objects created by the software will be in direct correspondence with such external objects,as in a payroll system that includes a class EMPLOYEE,whose run-time instances are computer models of employees. This dual use of the word"object"has some good consequences,which follow from “Direct Mapping”, the power of the object-oriented method as a modeling tool.Better than any other method,page47. object technology highlights and supports the modeling component of software development.This explains in part the impression of naturalness which it exudes,the attraction it exerts on so many people,and its early successes-still among the most visible-in such areas as simulation and user interfaces.The method here enjoys the direct mapping property which an earlier chapter described as a principal requirement of good modular design.With software systems considered to be direct or indirect models of real systems,it is not surprising that some classes will be models of external object types from the problem domain,so that the software objects(the instances of these classes)are themselves models of the corresponding external objects. But we should not let ourselves get too carried away by the word"object".As always in science and technology,it is a bit risky to borrow words from everyday language and give them technical meanings.(The only discipline which seems to succeed in this delicate art is mathematics,which routinely hijacks such innocent words as "neighborhood", s“variety”or“barrel'”and uses them with completely unexpected meanings一perhaps the
218 THE RUN-TIME STRUCTURE: OBJECTS §8.1 8.1 OBJECTS At any time during its execution, an O-O system will have created a certain number of objects. The run-time structure is the organization of these objects and of their relations. Let us explore its properties. What is an object? First we should recall what the word “object” means for this discussion. There is nothing vague in this notion; a precise technical definition was given in the previous chapter: A software system that includes a class C may at various points of its execution create (through creation and cloning operations, whose details appear later in this chapter) instances of C; such an instance is a data structure built according to the pattern defined by C; for example an instance of the class POINT introduced in the previous chapter is a data structure consisting of two fields, associated with the two attributes x and y declared in the class. The instances of all possible classes constitute the set of objects. The above definition is the official one for object-oriented software. But “object” also has a more general meaning, coming from everyday language. Any software system is related to some external system, which may contain “objects”: points, lines, angles, surfaces and solids in a graphics system: employees, pay checks and salary scales in a payroll system; and so on. Some of the objects created by the software will be in direct correspondence with such external objects, as in a payroll system that includes a class EMPLOYEE, whose run-time instances are computer models of employees. This dual use of the word “object” has some good consequences, which follow from the power of the object-oriented method as a modeling tool. Better than any other method, object technology highlights and supports the modeling component of software development. This explains in part the impression of naturalness which it exudes, the attraction it exerts on so many people, and its early successes — still among the most visible — in such areas as simulation and user interfaces. The method here enjoys the direct mapping property which an earlier chapter described as a principal requirement of good modular design. With software systems considered to be direct or indirect models of real systems, it is not surprising that some classes will be models of external object types from the problem domain, so that the software objects (the instances of these classes) are themselves models of the corresponding external objects. But we should not let ourselves get too carried away by the word “object”. As always in science and technology, it is a bit risky to borrow words from everyday language and give them technical meanings. (The only discipline which seems to succeed in this delicate art is mathematics, which routinely hijacks such innocent words as “neighborhood”, “variety” or “barrel” and uses them with completely unexpected meanings — perhaps the Definition: object An object is a run-time instance of some class. The definition appeared on page 166. See also the Object rule, page 171. “Direct Mapping”, page 47
$8.1 OBJECTS 219 reason why no one seems to have any trouble.)The term "object"is so overloaded with everyday meanings that in spite of the benefits just mentioned its use in a technical software sense has caused its share of confusion.In particular: As pointed out in the discussion of direct mapping,not all classes correspond to object types of the problem domain.The classes introduced for design and implementation have no immediate counterparts in the modeled system.They are often among the most important in practice,and the most difficult to find. See chapter 20about Some concepts from the problem domain may yield classes in the software (and the form-based sys- objects in the software's execution)even though they would not necessarily be tem.About the classified as objects in the usual sense of the term if we insist on a concrete view of notion ofcommand, see chapter 21. objects.A class such as STATE in the discussion of the form-based interactive system,or COMMAND(to be studied in a later chapter in connection with undo-redo mechanisms)fall in this category. When the word "object"is used in this book,the context will clearly indicate whether the usual meaning or(more commonly)the technical software meaning is intended.When there is a need to distinguish,one may talk about external objects and software objects. Basic form A software object is a rather simple animal once you know what class it comes from. Let O be an object.The definition on the previous page indicates that it is an instance of some class.More precisely,it is a direct instance of just one class,say C. Because of inheritance,O will then be an instance,direct or not,of other classes,the ancestors of C;but that is a matter for a future chapter,and for the present discussion we only need the notion of direct instance.The word "direct"will be dropped when there is no possible confusion. C is called the generating class,or just generator,ofO.C is a software text;O is a run-time data structure,produced by one ofthe object creation mechanisms studied below. Among its features,C has a certain number of attributes.These attributes entirely determine the form of the object:O is simply a collection of components,or fields,one for each attribute. Consider class PO/NT from the previous chapter.The class text was of the form: For the text of class class POINT feature POINT see page x,y:REAL 176. ..Routine declarations... end The routines have been omitted,and for good reason:the form of the corresponding objects (the direct instances of the class)is solely determined by the attributes,although the operations applicable to the objects depend on the routines.Here the class has two attributes,x andy,both of type REAL,so a direct instance of POINT is an object with two fields containing values of that type,for example:
§8.1 OBJECTS 219 reason why no one seems to have any trouble.) The term “object” is so overloaded with everyday meanings that in spite of the benefits just mentioned its use in a technical software sense has caused its share of confusion. In particular: • As pointed out in the discussion of direct mapping, not all classes correspond to object types of the problem domain. The classes introduced for design and implementation have no immediate counterparts in the modeled system. They are often among the most important in practice, and the most difficult to find. • Some concepts from the problem domain may yield classes in the software (and objects in the software’s execution) even though they would not necessarily be classified as objects in the usual sense of the term if we insist on a concrete view of objects. A class such as STATE in the discussion of the form-based interactive system, or COMMAND (to be studied in a later chapter in connection with undo-redo mechanisms) fall in this category. When the word “object” is used in this book, the context will clearly indicate whether the usual meaning or (more commonly) the technical software meaning is intended. When there is a need to distinguish, one may talk about external objects and software objects. Basic form A software object is a rather simple animal once you know what class it comes from. Let O be an object. The definition on the previous page indicates that it is an instance of some class. More precisely, it is a direct instance of just one class, say C. Because of inheritance, O will then be an instance, direct or not, of other classes, the ancestors of C; but that is a matter for a future chapter, and for the present discussion we only need the notion of direct instance. The word “direct” will be dropped when there is no possible confusion. C is called the generating class, or just generator, of O. C is a software text; O is a run-time data structure, produced by one of the object creation mechanisms studied below. Among its features, C has a certain number of attributes. These attributes entirely determine the form of the object: O is simply a collection of components, or fields, one for each attribute. Consider class POINT from the previous chapter. The class text was of the form: class POINT feature x, y: REAL … Routine declarations … end The routines have been omitted, and for good reason: the form of the corresponding objects (the direct instances of the class) is solely determined by the attributes, although the operations applicable to the objects depend on the routines. Here the class has two attributes, x and y, both of type REAL, so a direct instance of POINT is an object with two fields containing values of that type, for example: See chapter 20 about the form-based system. About the notion of command, see chapter 21. For the text of class POINT see page 176
220 THE RUN-TIME STRUCTURE:OBJECTS $8.1 P OBJ 3.4 -8.09 (POINT) Notice the conventions used here and in the rest of this book for representing an object as See "Graphical con- a set of fields,shown as adjacent rectangles containing the associated values.Below the ventions”,page27l. object the name ofthe generating class,here POIN7,appears in parentheses and in italics; next to each field,also in italics,there appears the name of the corresponding attribute, here x and y.Sometimes a name in roman (here P_OBJ)will appear above the object;it has no counterpart in the software but identifies the object in the discussion. In diagrams used to show the structure of an object-oriented system,or more commonly of some part of such a system,classes appear as ellipses.This convention,already used in the figures of the previous chapter,avoids any confusion between classes and objects. Simple fields Both attributes of class POIN7 are of type REAL.As a consequence,each of the corresponding fields of a direct instance of POINT contains a real value. This is an example ofa field corresponding to an attribute of one of the"basic types". Although these types are formally defined as classes,their instances take their values from predefined sets implemented efficiently on computers.They include: BOOLEAN,which has exactly two instances,representing the boolean values true and false. CHARACTER,whose instances represent characters. INTEGER,whose instances represent integers. RE4L and DOUBLE,whose instances represent single-precision and double- precision floating-point numbers. Another type which for the time being will be treated as a basic type,although we "STRINGS".13.5. will later see that it is actually in a different category,is STRING,whose instances page 456. represent finite sequences of characters. For each of the basic types we will need the ability to denote the corresponding values in software texts and on figures.The conventions are straightforward: For BOOLEAN,the two instances are written True and False. To denote an instance of CHARACTER you will write a character enclosed in single quotes,such as
220 THE RUN-TIME STRUCTURE: OBJECTS §8.1 Notice the conventions used here and in the rest of this book for representing an object as a set of fields, shown as adjacent rectangles containing the associated values. Below the object the name of the generating class, here POINT, appears in parentheses and in italics; next to each field, also in italics, there appears the name of the corresponding attribute, here x and y. Sometimes a name in roman (here P_OBJ) will appear above the object; it has no counterpart in the software but identifies the object in the discussion. In diagrams used to show the structure of an object-oriented system, or more commonly of some part of such a system, classes appear as ellipses. This convention, already used in the figures of the previous chapter, avoids any confusion between classes and objects. Simple fields Both attributes of class POINT are of type REAL. As a consequence, each of the corresponding fields of a direct instance of POINT contains a real value. This is an example of a field corresponding to an attribute of one of the “basic types”. Although these types are formally defined as classes, their instances take their values from predefined sets implemented efficiently on computers. They include: • BOOLEAN, which has exactly two instances, representing the boolean values true and false. • CHARACTER, whose instances represent characters. • INTEGER, whose instances represent integers. • REAL and DOUBLE, whose instances represent single-precision and doubleprecision floating-point numbers. Another type which for the time being will be treated as a basic type, although we will later see that it is actually in a different category, is STRING, whose instances represent finite sequences of characters. For each of the basic types we will need the ability to denote the corresponding values in software texts and on figures. The conventions are straightforward: • For BOOLEAN, the two instances are written True and False. • To denote an instance of CHARACTER you will write a character enclosed in single quotes, such as 'A'. 3.4 –8.09 x y (POINT) P_OBJ See “Graphical conventions”, page 271. “STRINGS”, 13.5, page 456
§8 1 OBJECTS 221 To denote an instance of STR/NG,write a sequence of characters in double quotes, as in "A STRING". To denote an instance of /NTEGER,write a number in an ordinary decimal notation with an optional sign,as in 34,-675 and +4. You can also write an instance of REAL or DOUBLE in ordinary notation,as in 3.5 or-0.05.Use the letter e to introduce a decimal exponent,as in-5.e-2 which denotes the same value as the preceding example. A simple notion of book Here is a class with attribute types taken from the preceding set: class BOOK/feature title:STRING date,page count:INTEGER end A typical instance of class BOOKI may appear as follows: An object title "The Red and the Black" representing a book date 1830 page count 341 (BOOKI) Since for the moment we are only interested in the structure of objects,all the features in this class and the next few examples are attributes-none are routines. This means that our objects are similar at this stage to the records or structure types of non-object-oriented languages such as Pascal and C.But unlike the situation in these languages there is little we can do with such a class in a good O-O language:because of the information hiding mechanisms,a client class has no way of assigning values to the fields of such objects.In Pascal,or in C with a slightly different syntax,a record type with a similar structure would allow a client to include the declaration and instruction bl:BOOKI Warning:not per- bl-page count 355 mitted in the O-O notation!For dis- which at run time will assign value 355 to the page com field of the object attached to cussion only. b/.With classes,however,we should not provide any such facility:letting clients change object fields as they please would make a mockery of the rule of information hiding,which
§8.1 OBJECTS 221 • To denote an instance of STRING, write a sequence of characters in double quotes, as in "A STRING". • To denote an instance of INTEGER, write a number in an ordinary decimal notation with an optional sign, as in 34, –675 and +4. • You can also write an instance of REAL or DOUBLE in ordinary notation, as in 3.5 or –0.05. Use the letter e to introduce a decimal exponent, as in –5.e–2 which denotes the same value as the preceding example. A simple notion of book Here is a class with attribute types taken from the preceding set: class BOOK1 feature title: STRING date, page_count: INTEGER end A typical instance of class BOOK1 may appear as follows: Since for the moment we are only interested in the structure of objects, all the features in this class and the next few examples are attributes — none are routines. This means that our objects are similar at this stage to the records or structure types of non-object-oriented languages such as Pascal and C. But unlike the situation in these languages there is little we can do with such a class in a good O-O language: because of the information hiding mechanisms, a client class has no way of assigning values to the fields of such objects. In Pascal, or in C with a slightly different syntax, a record type with a similar structure would allow a client to include the declaration and instruction b1: BOOK1 … b1 ● page_count := 355 which at run time will assign value 355 to the page_count field of the object attached to b1. With classes, however, we should not provide any such facility: letting clients change object fields as they please would make a mockery of the rule of information hiding, which An object representing a book "The Red and the Black" 1830 title date (BOOK1) page_count 341 Warning: not permitted in the O-O notation! For discussion only