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