Object Orientation in Font

Generation QR Code in Font Object Orientation

It sometimes seems to me that every term used in the world of object orientation is just a new label for something that s been known for years in other contexts under some more familiar name. Of course, the problem is exacerbated by the fact that there doesn t seem to be consensus on the meanings of terms even within the object world; however, I think it s fair to say that the key concepts regardless of what names they go by are class, method, message, encapsulation, and of course object itself. I ll defer discussion of the last of these to a later chapter, 6 (there s a lot to be said about it!). As for the rest: Class seems to be indistinguishable from type, as that term is classically understood. Method seems to be indistinguishable from operator, as that term is classically understood except that in some object systems methods are selfish, meaning they re effectively a special kind of operator: namely, one that treats one particular parameter as special (a state of affairs that makes life easier for the system but harder for the user). Message seems to be indistinguishable from operator invocation, as that term is classically understood unless the method concerned is selfish, in which case the minor exception noted under the previous point applies essentially unchanged. Finally, to say something is encapsulated seems to be indistinguishable from saying it s scalar, as that term is classically understood. There is, of course, another concept that s frequently discussed in the object world: class hierarchy. Here are some synonyms for that term: type hierarchy inheritance hierarchy generalization hierarchy specialization hierarchy ISA hierarchy Note: I make the foregoing claims i.e., regarding logical sameness in the object world in full knowledge of the fact that many people will object to them (pun intended). For example,

take the case of class and type. Here s a quote from a textbook on object database systems that discusses this issue: Object-oriented systems can be classified into two main categories systems supporting the notion of class and those supporting the notion of type ... [Although] there are no clear lines of demarcation between them, the two concepts are fundamentally different [sic!] ... Often the concepts type and class are used interchangeably. [But I thought they were fundamentally different ]. However, when both are present in the same language, the type is used to indicate the specification of the interface of a set of objects, while class is an implementational notion. [So why is the class concept in the language at all ]. Therefore ... a type is a set of objects which share the same behavior ... [and] a class is a set of objects which have exactly the same internal structure and therefore the same attributes and the same methods. [But if all objects in a class have the same attributes and the same methods, is not that class a type, by the book s own definition ] The class defines the implementation of a set of objects, while a type describes how such objects can be used. [Contrast ODMG,3 which at least in some contexts if not all uses the terms type and class in a very different way.] (This extract is taken from Object-Oriented Database Systems: Concepts and Architectures, by Elisa Bertino and Lorenzo Martino, Addison-Wesley, 1993. The annotation is mine, of course.) A little later in the same book, we also find this: With inheritance, a class called a subclass can be defined on the basis of the definition of another class called a superclass. [Surely in accordance with its own earlier definitions the book should be talking in terms of types here, not classes ] ... The specification hierarchy (often called subtype hierarchy) expresses ... subtyping relationships which mean that an instance of the subtype can be used in every context in which an instance of the supertype can correctly appear (substitutability). [Observe that it does now speak of types, not classes. Observe too that we now have two more terms for the type hierarchy.] Note: As an aside, I d like to quote here a passage from the preface to A Dictionary of Modern American Usage, by Bryan A. Garner (Oxford University Press, 1998): I should address a question that many readers will wonder about. Should I really name names Should I give full citations in the way that I do Won t it mortify a [writer] to find some badly written sentence [quoted] for all the world to see ... Well, I hope it isn t mortifying, and for me it s nothing new ... The citations appear for three reasons. First, they show that the examples are real, not fabricated. Second, they show the great variety of evidence on which [my] judgments are based ... And third, ...they reflect how the language is being used in our culture in our time. I concur!

3. R. G. G. Cattell and Douglas K. Barry (eds.): The Object Data Standard: ODMG 3.0. San Francisco, Calif.: Morgan Kaufmann (2000).