南京大学：《面向对象技术 OOT》课程教学资源（教材电子版）07 The static structure：classes.pdf

166 THE STATIC STRUCTURE:CLASSES $7.2 Like an ADT,a class is a type:it describes a set of possible data structures,called the instances of the class.Abstract data types too have instances;the difference is that an instance of an ADT is a purely mathematical element(a member of some mathematical set),whereas an instance of a class is a data structure that may be represented in the memory of a computer and manipulated by a software system. For example if we have defined a class STACK by taking the ADT specification of the previous chapter and adding adequate representation information,the instances of that class will be data structures representing individual stacks.Another example,developed in the rest of this chapter,is a class PO/N7 modeling the notion of point in a two- dimensional space,under some appropriate representation;an instance of that class is a data structure representing a point.Under one of the representations studied below,the cartesian representation,each instance of POINT is a record with two fields representing the horizontal and vertical coordinates,x and y,of a point. The definition of"class"yields as a byproduct a definition of"object".An object is simply an instance of some class.For example an instance of class STACK-a data structure representing a particular stack-is an object;so is an instance of class PO/N7, representing a particular point in two-dimensional space. The software texts that serve to produce systems are classes.Objects are a run-time notion only:they are created and manipulated by the software during its execution. The present chapter is devoted to the basic mechanisms for writing software elements and combining them into systems;as a consequence,its focus is on classes.In the next chapter,we will explore the run-time structures generated by an object-oriented system;this will require us to study some implementation issues and to take a closer look at the nature of objects. 7.2 AVOIDING THE STANDARD CONFUSION A class is a model,and an object is an instance of such a model.This property is so obvious The next section,for that it would normally deserve no comments beyond the preceding definitions;but is has readers who do not been the victim of so much confusion in the more careless segment of the literature that like the belaboring of the obvious,is we must take some time to clarify the obvious.(If you feel that you are immune to such a “THE ROLE OF danger,and have avoided exposure to sloppy object-oriented teaching,you may wish to CLASSES”,7.3, skip this section altogether as it essentially belabors the obvious. page 169. What would you think of this? Among the countries in Europe we may identify the Italian.The Italian has a mountain chain running through him North-South and he likes good cooking,often using olive oil.His climate is of the Mediterranean type,and he speaks a beautifully musical language

166 THE STATIC STRUCTURE: CLASSES §7.2 Like an ADT, a class is a type: it describes a set of possible data structures, called the instances of the class. Abstract data types too have instances; the difference is that an instance of an ADT is a purely mathematical element (a member of some mathematical set), whereas an instance of a class is a data structure that may be represented in the memory of a computer and manipulated by a software system. For example if we have defined a class STACK by taking the ADT specification of the previous chapter and adding adequate representation information, the instances of that class will be data structures representing individual stacks. Another example, developed in the rest of this chapter, is a class POINT modeling the notion of point in a twodimensional space, under some appropriate representation; an instance of that class is a data structure representing a point. Under one of the representations studied below, the cartesian representation, each instance of POINT is a record with two fields representing the horizontal and vertical coordinates, x and y, of a point. The definition of “class” yields as a byproduct a definition of “object”. An object is simply an instance of some class. For example an instance of class STACK — a data structure representing a particular stack — is an object; so is an instance of class POINT, representing a particular point in two-dimensional space. The software texts that serve to produce systems are classes. Objects are a run-time notion only: they are created and manipulated by the software during its execution. The present chapter is devoted to the basic mechanisms for writing software elements and combining them into systems; as a consequence, its focus is on classes. In the next chapter, we will explore the run-time structures generated by an object-oriented system; this will require us to study some implementation issues and to take a closer look at the nature of objects. 7.2 AVOIDING THE STANDARD CONFUSION A class is a model, and an object is an instance of such a model. This property is so obvious that it would normally deserve no comments beyond the preceding definitions; but is has been the victim of so much confusion in the more careless segment of the literature that we must take some time to clarify the obvious. (If you feel that you are immune to such a danger, and have avoided exposure to sloppy object-oriented teaching, you may wish to skip this section altogether as it essentially belabors the obvious.) What would you think of this? Among the countries in Europe we may identify the Italian. The Italian has a mountain chain running through him North-South and he likes good cooking, often using olive oil. His climate is of the Mediterranean type, and he speaks a beautifully musical language. The next section, for readers who do not like the belaboring of the obvious, is “THE ROLE OF CLASSES”, 7.3, page 169

$7.2 AVOIDING THE STANDARD CONFUSION 167 See e.g.Oliver If someone in a sober state talked or wrote to you in this fashion,you might suspect a new Sacks,The Man neurological disease,the inability to distinguish between categories(such as the Italian Who Mistook His Wife for a Hat and nation)and individuals members of these categories (such as individual Italians),reason Other Clinical enough to give to the ambulance driver the address of Dr.Sacks's New York clinic Tales",Harper Perennials,1991. Yet in the object-oriented software literature similar confusions are common. Consider the following extract from a popular book on O-O analysis,which uses the example of an interactive system to discuss how to identify abstractions: [Coad1990]3.3.3, [Wle might identify a "User"Object in a problem space where the system page 67. does not need to keep any information about the user.In this case,the system does not need the usual identification number,name,access privilege,and the like.However,the system does need to monitor the user,responding to requests and providing timely information.And so,because of required Services on behalfof the real world thing (in this case,User),we need to add a corresponding Object to the model of the problem space. In the same breath this text uses the word objects,user and thing in two meanings belonging to entirely different levels of abstraction: Exercise E7.1,page A typical user of the interactive system under discussion. 216,asks you to clarify each use of The concept of user in general. “Object”in this tex.. Although this is probably a slip of terminology(a peccadillo which few people can claim never to have committed)rather than a true confusion on the authors'part,it is unfortunately representative of how some of the literature deals with the model-instance distinction.If you start the study of a new method with this kind of elementary mix-up, real or apparent,you are not likely to obtain a rational approach to software construction. The mold and the instance Take this book-the copy which you are currently reading.Consider it as an object in the common sense of the term.It has its own individual features:the copy may be brand new, or already thumbed by previous readers;perhaps you wrote your name on the first page; or it belongs to a library and has a local identification code impressed on its spine. The basic properties of the book,however,such as its title,publisher,author and contents,are determined by a general description which applies to every individual copy: the book is entitled Object-Oriented Software Construction,it is published by Prentice Hall,it talks about the object-oriented method,and so on.This set of properties defines not an object but a class of objects(also called,in this case,the type of these objects;for the time being the notions of type and class may be considered synonymous). Call the class OOSC.It defines a certain mold.Objects built from this mold,such as your copy of the book,are called instances of the class.Another example of mold would be the plaster cast that a sculptor makes to obtain an inverted version of the design for a set of identical statues;any statue derived from the cast is an instance of the mold

§7.2 AVOIDING THE STANDARD CONFUSION 167 If someone in a sober state talked or wrote to you in this fashion, you might suspect a new neurological disease, the inability to distinguish between categories (such as the Italian nation) and individuals members of these categories (such as individual Italians), reason enough to give to the ambulance driver the address of Dr. Sacks’s New York clinic. Yet in the object-oriented software literature similar confusions are common. Consider the following extract from a popular book on O-O analysis, which uses the example of an interactive system to discuss how to identify abstractions: In the same breath this text uses the word objects, user and thing in two meanings belonging to entirely different levels of abstraction: • A typical user of the interactive system under discussion. • The concept of user in general. Although this is probably a slip of terminology (a peccadillo which few people can claim never to have committed) rather than a true confusion on the authors’ part, it is unfortunately representative of how some of the literature deals with the model-instance distinction. If you start the study of a new method with this kind of elementary mix-up, real or apparent, you are not likely to obtain a rational approach to software construction. The mold and the instance Take this book — the copy which you are currently reading. Consider it as an object in the common sense of the term. It has its own individual features: the copy may be brand new, or already thumbed by previous readers; perhaps you wrote your name on the first page; or it belongs to a library and has a local identification code impressed on its spine. The basic properties of the book, however, such as its title, publisher, author and contents, are determined by a general description which applies to every individual copy: the book is entitled Object-Oriented Software Construction, it is published by Prentice Hall, it talks about the object-oriented method, and so on. This set of properties defines not an object but a class of objects (also called, in this case, the type of these objects; for the time being the notions of type and class may be considered synonymous). Call the class OOSC. It defines a certain mold. Objects built from this mold, such as your copy of the book, are called instances of the class. Another example of mold would be the plaster cast that a sculptor makes to obtain an inverted version of the design for a set of identical statues; any statue derived from the cast is an instance of the mold. [W]e might identify a “User” Object in a problem space where the system does not need to keep any information about the user. In this case, the system does not need the usual identification number, name, access privilege, and the like. However, the system does need to monitor the user, responding to requests and providing timely information. And so, because of required Services on behalf of the real world thing (in this case, User), we need to add a corresponding Object to the model of the problem space. See e.g. Oliver Sacks, ``The Man Who Mistook His Wife for a Hat and Other Clinical Tales'', Harper Perennials, 1991. [Coad 1990], 3.3.3, page 67. Exercise E7.1, page 216, asks you to clarify each use of “Object” in this text

168 THE STATIC STRUCTURE:CLASSES $7.2 In the quotation from The Name ofthe Rose which opens part C,the Master is explaining Page 163. how he was able to determine,from traces of the snow,that Brownie,the Abbot's horse, earlier walked here.Brownie is an instance of the class of all horses.The sign on the snow,although imprinted by one particular instance,includes only enough information to determine the class (horse),not its identity (Brownie).Since the class,like the sign, identifies all horses rather than a particular horse,the extract calls it a sign too. Exactly the same concepts apply to software objects.What you will write in your software systems is the description of classes,such as a class LINKED STACK describing properties of stacks in a certain representation.Any particular execution of your system may use the classes to create objects(data structures);each such object is derived from a class,and is called an instance of that class.For example the execution may create a linked stack object,derived from the description given in class LINKED STACK;such an object is an instance of class LINKED STACK. The class is a software text.It is static;in other words,it exists independently ofany execution.In contrast,an object derived from that class is a dynamically created data structure,existing only in the memory of a computer during the execution of a system. This,of course,is in line with the earlier discussion of abstract data types:when specifying STACK as an ADT,we did not describe any particular stack,but the general notion of stack,a mold from which one can derive individual instances ad libitum. The statements "x is an instance of T"and"x is an object of type T"will be considered synonymous for this discussion. With the introduction of inheritance we will need to distinguish between the direct See“Instances” instances of a class(built from the exact pattern defined by the class)and its instances in page 475. the more general sense (direct instances of the class or any of its specializations). Metaclasses Why would so many books and articles confuse two so clearly different notions as class and object?One reason一although not an excuse一is the appeal of the word“object”,a simple term from everyday language.But it is misleading.As we already saw in the discussion of seamlessness,although some of the objects (class instances)which O-O systems manipulate are the computer representations of objects in the usual sense of the term,such as documents,bank accounts or airplanes,many others have no existence outside of the software;they include in particular the objects introduced for design and implementation purposes-instances of classes such as STATE or LINKED L/ST Another possible source of confusion between objects and classes is that in some cases we may need to treat classes themselves as objects.This need arises only in special contexts,and is mainly relevant to developers of object-oriented development environments.For example a compiler or interpreter for an O-O language will manipulate data structures representing classes written in that language.The same would hold of other tools such as a browser (a tool used to locate classes and find out about their properties) or a configuration management system.If you produce such tools,you will create objects that represent classes

168 THE STATIC STRUCTURE: CLASSES §7.2 In the quotation from The Name of the Rose which opens part C, the Master is explaining how he was able to determine, from traces of the snow, that Brownie, the Abbot’s horse, earlier walked here. Brownie is an instance of the class of all horses. The sign on the snow, although imprinted by one particular instance, includes only enough information to determine the class (horse), not its identity (Brownie). Since the class, like the sign, identifies all horses rather than a particular horse, the extract calls it a sign too. Exactly the same concepts apply to software objects. What you will write in your software systems is the description of classes, such as a class LINKED_STACK describing properties of stacks in a certain representation. Any particular execution of your system may use the classes to create objects (data structures); each such object is derived from a class, and is called an instance of that class. For example the execution may create a linked stack object, derived from the description given in class LINKED_STACK; such an object is an instance of class LINKED_STACK. The class is a software text. It is static; in other words, it exists independently of any execution. In contrast, an object derived from that class is a dynamically created data structure, existing only in the memory of a computer during the execution of a system. This, of course, is in line with the earlier discussion of abstract data types: when specifying STACK as an ADT, we did not describe any particular stack, but the general notion of stack, a mold from which one can derive individual instances ad libitum. The statements “x is an instance of T” and “x is an object of type T” will be considered synonymous for this discussion. With the introduction of inheritance we will need to distinguish between the direct instances of a class (built from the exact pattern defined by the class) and its instances in the more general sense (direct instances of the class or any of its specializations). Metaclasses Why would so many books and articles confuse two so clearly different notions as class and object? One reason — although not an excuse — is the appeal of the word “object”, a simple term from everyday language. But it is misleading. As we already saw in the discussion of seamlessness, although some of the objects (class instances) which O-O systems manipulate are the computer representations of objects in the usual sense of the term, such as documents, bank accounts or airplanes, many others have no existence outside of the software; they include in particular the objects introduced for design and implementation purposes — instances of classes such as STATE or LINKED_LIST. Another possible source of confusion between objects and classes is that in some cases we may need to treat classes themselves as objects. This need arises only in special contexts, and is mainly relevant to developers of object-oriented development environments. For example a compiler or interpreter for an O-O language will manipulate data structures representing classes written in that language. The same would hold of other tools such as a browser (a tool used to locate classes and find out about their properties) or a configuration management system. If you produce such tools, you will create objects that represent classes. Page 163. See “Instances”, page 475

$7.3 THE ROLE OF CLASSES 169 Pursuing an analogy used earlier,we may compare this situation to that of a Prentice Hall employee who is in charge of preparing the catalog of software engineering titles.For the catalog writer,OOSC,the concept behind this book,is an object-an instance of a class "catalog entry".In contrast,for the reader of the book,that concept is a class,of which the reader's particular copy is an instance. Some object-oriented languages,notably Smalltalk,have introduced a notion of metaclass to handle this kind of situation.A metaclass is a class whose instances are themselves classes-what the Name of the Rose extract called"signs of signs". We will avoid metaclasses in this presentation,however,since they bring more problems than benefits.In particular,the addition of metaclasses makes it difficult to have static type checking,a required condition of the production of reliable software.The main applications of metaclasses are better obtained through other mechanisms anyway: “Universal c☑lasses” You can use metaclasses to make a set of features available to many or all classes page 580. We will achieve the same result by arranging the inheritance structure so that all classes are descendants of a general-purpose,customizable class ANY,containing the declarations of universal features. See“The creation A few operations may be viewed as characterizing a class rather than its instances, instruction",page justifying their inclusion as features of a metaclass.But these operations are few and 232. known;the most obvious one is object creation-sufficiently important to deserve a special language construct,the creation instruction.(Other such operations,such as object duplication,will be covered by features of class ANY.) There remains the use of metaclasses to obtain information about a class,such as a browser may need:name of the class,list of features,list of parents,list of suppliers etc.But we do not need metaclasses for that.It will suffice to devise a library class, E CLASS,so that each instance of E CLASS represents a class and its properties. When we create such an instance,we pass to the creation instruction an argument representing a certain class C;then by applying the various features of E CLASS to that instance,we can learn all about C. In practice,then,we can do without a separate concept of metaclass.But even in a method,language or environment that would support this notion,the presence of metaclasses is no excuse for confusing molds and their instances-classes and objects. 7.3 THE ROLE OF CLASSES Having taken the time to remove an absurd but common and damaging confusion,we may now come back to the central properties ofclasses,and in particular study why they are so important to object technology. To understand the object-oriented approach,it is essential to realize that classes play two roles which pre-O-O approaches had always treated as separate:module and type

§7.3 THE ROLE OF CLASSES 169 Pursuing an analogy used earlier, we may compare this situation to that of a Prentice Hall employee who is in charge of preparing the catalog of software engineering titles. For the catalog writer, OOSC, the concept behind this book, is an object — an instance of a class “catalog entry”. In contrast, for the reader of the book, that concept is a class, of which the reader’s particular copy is an instance. Some object-oriented languages, notably Smalltalk, have introduced a notion of metaclass to handle this kind of situation. A metaclass is a class whose instances are themselves classes — what the Name of the Rose extract called “signs of signs”. We will avoid metaclasses in this presentation, however, since they bring more problems than benefits. In particular, the addition of metaclasses makes it difficult to have static type checking, a required condition of the production of reliable software. The main applications of metaclasses are better obtained through other mechanisms anyway: • You can use metaclasses to make a set of features available to many or all classes. We will achieve the same result by arranging the inheritance structure so that all classes are descendants of a general-purpose, customizable class ANY, containing the declarations of universal features. • A few operations may be viewed as characterizing a class rather than its instances, justifying their inclusion as features of a metaclass. But these operations are few and known; the most obvious one is object creation — sufficiently important to deserve a special language construct, the creation instruction. (Other such operations, such as object duplication, will be covered by features of class ANY.) • There remains the use of metaclasses to obtain information about a class, such as a browser may need: name of the class, list of features, list of parents, list of suppliers etc. But we do not need metaclasses for that. It will suffice to devise a library class, E_CLASS, so that each instance of E_CLASS represents a class and its properties. When we create such an instance, we pass to the creation instruction an argument representing a certain class C; then by applying the various features of E_CLASS to that instance, we can learn all about C. In practice, then, we can do without a separate concept of metaclass. But even in a method, language or environment that would support this notion, the presence of metaclasses is no excuse for confusing molds and their instances — classes and objects. 7.3 THE ROLE OF CLASSES Having taken the time to remove an absurd but common and damaging confusion, we may now come back to the central properties of classes, and in particular study why they are so important to object technology. To understand the object-oriented approach, it is essential to realize that classes play two roles which pre-O-O approaches had always treated as separate: module and type. “Universal classes”, page 580. See “The creation instruction”, page 232