$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