Introduction
Archive-name: object-faq/announce
Last-Modified: 12/13/93
Version: 1.0.5
This announces the December version 1.0.5 of the Comp.Object FAQ! It has many
updates and corrections and has several very up-to-date appendices on object-
oriented methodologies and systems. While a new section on miscellaneous
commercial systems and libraries is still in the works for completeness, this
document may very well comprise the latest and most up-to-date collection of
object-oriented systems and terms in the world today! There is also a
potential upcoming merge with the new C++ Libraries FAQ.
New noteworthy additions are the OO methodologies and OOA/OOD sections and ever
expanding appendices. Future FAQs will contain a diff file. The FAQ is
updated and posted monthly. Comments, suggestions, additions, updates, and new
systems and site entries should be sent to rjh@geodesic.com.
The FAQ is posted to the comp.object, comp.answers and news.answers newsgroups
and is available via anonymous ftp from zaphod.uchicago.edu and rtfm.mit.edu,
although new versions may take a short period of time to be installed.
Anonymous FTP Sites and Hypertext Server:
anonymous@zaphod.uchicago.edu:/pub/comp.object-faq.1.0.5(.Z) (128.135.72.61)
anonymous@rtfm.mit.edu:/pub/usenet/comp.object/*_Part_*
http://cui_www.unige.ch/OSG/FAQ/OO-FAQ/index.html
Mail Server: (See also section 1.24)
mail mail-server@rtfm.mit.edu
Subject:
send usenet/comp.object/*
Zaphod is preferred over rtfm for anonymous ftp retrieval, as it provides a
single file. Rtfm contains the FAQ as posted.
To use the hypertext system, see APPENDIX E, entries 27.
Again, a short period of time may be required to retrieve the latest version,
allowing the posted version to propagate and get out as quickly as possible.
Thank you to the many people who have contributed their time and effort into
helping this document spread the word about object-oriented technology and
available systems! It is hoped it will be most useful in that endeavor.
Best Regards!
bob
COMP.OBJECT FAQ
Version: 1.0.5
Date: 12/13/1993
Author:
Bob Hathaway
Geodesic Systems
rjh@geodesic.com
Anonymous FTP Sites and Hypertext Server:
anonymous@zaphod.uchicago.edu:/pub/comp.object-faq.1.0.5(.Z) (128.135.72.61)
anonymous@rtfm.mit.edu:/pub/usenet/comp.object/*_Part_*
http://cui_www.unige.ch/OSG/FAQ/OO-FAQ/index.html
Mail Server: (See also section 1.24)
mail mail-server@rtfm.mit.edu
Subject:
send usenet/comp.object/*
Zaphod is preferred over rtfm for anonymous ftp retrieval, as it provides a
single file. Rtfm contains the FAQ as posted.
To use the hypertext system, see APPENDIX E, entries 27.
There is currently no comp.object archive.
Copyright 1992-1994 Bob Hathaway
All rights reserved.
Permission is granted to freely copy and distribute this document but only at
no cost to others and with the exception of a nominal distribution fee, if
any. No sale, resale or reprinting is granted without the explicit written
permission of the author.
Contributors: Per Abrahamsen, Stewart Clamen, Edwardo Casais, Dennis De
Champeaux, Mike DeVaney, Eric Dujardin, Piercarlo Grandi, Brian Henderson-
Sellers, Urs Hoelzle, Paul Johnson, Bill Kinnersley, James Odell, Eoin Woods
and many others whose contributions have helped this document to fulfull its
objective of bringing object-oriented concepts and systems to everyone.
Objective:
In the spirit of other FAQs, to provide a simple document to answer the most
frequently asked and recurring questions and to allow new users to understand
frequently discussed topics and terms used in comp.object. This should
bring new comp.object readers and/or writers to at least an introductory
level of comprehension as soon as possible. Other goals (hopes) are to
provide a quick and current reference on available systems such as object-
oriented languages, CASE, OODB and etc. and to provide good references to
current and relevant OO systems, groups, texts and literature.
Disclaimer:
This document does not necessarily reflect the opinions of the author's or
any contributor's companies. There are no explicit or implicit guarantees
implied by this document.
While object systems are a constantly changing and moving target with a broad
diversity of often conflicting methodologies, constructs, terminologies,
approaches, languages, implementations and etc. and comp.object has a wide
diversity of readers and writers ranging from students, professors and
researchers in academia to beginners, professionals, top-notch experts and
leaders in industry with a broad range of experience and backgrounds ranging
across many paradigms, this FAQ can certainly not aspire to satisfy all of them
completely but instead attempts to provide the most well-rounded treatment of
object-oriented concepts and realizations primarily from the mainstream and
popular authors and systems and further to provide a collection of available
systems and tools in the appendices.
It should be understood that it is not possible to present a complete,
unbiased, and perfect document on the subject to be everything to all
people; however, herein lies at least one effort to provide a reasonable
compromise.
Several improvements are planned for future FAQs, including a glossary.
SECTION 1: BASICS
1.1) What Is An Object?
1.2) What Is Object Encapsulation (Or Protection)?
1.3) What Is A Class?
1.4) What Is A Meta-Class?
1.5) What Is The Infinite Regress Of Objects And Classes?
1.6) What are MOPs and Reflection?
1.7) What Is Inheritance?
1.8) What Is Multiple Inheritance?
1.9) Does Multiple Inheritance Pose Any Additional Difficulties?
1.10) What Is Dynamic Inheritance?
1.11) What Is Shared (Repeated) Inheritance?
1.12) Why Use Inheritance?
1.13) Why Don't Some People Like Inheritance?
1.14) What Is Specialization/Generalization/Overriding?
1.15) What Is The Difference Between Object-Based And Object-Oriented?
1.16) Is A Class An Object?
1.17) Is An Object A Class?
1.18) What Is A Method? (And Receiver And Message)
1.19) What Are Multi-Methods And Multiple-Polymorphism?
1.20) What Is OOP?
1.21) What Is OOA/OOD (And Where Can I Get What I Need On It)?
1.22) Where Did Object-Orientation Come From?
1.23) What Are The Benefits Of Object-Orientation?
1.24) What Other FAQs Are available?
SECTION 2: TYPING
2.1) What Is Polymorphism?
2.2) What Does Polymorphism Boil Down To In OO Programming Languages?
2.3) What Is Dynamic Binding?
2.4) Is There A Difference Between Being A Member Or Instance Of A Class?
2.5) What Is This I Read About ML And Functional Programming Languages?
2.6) What Is the Difference Between Static And Dynamic Typing?
2.7) What Is A Separation Between Type And Class (Representation)?
2.8) What Are Generics And Templates?
SECTION 3: GENERAL
3.1) What Is The "Classical" Object-Oriented Paradigm?
3.2) What Is The "Delegation/Prototyping" Object-Oriented Paradigm?
3.3) Are There Any Other Object-Oriented Paradigms?
3.4) What Are The Major Object-Oriented Programming Languages Today?
3.5) What Are Object-Oriented Databases And Persistence?
3.6) What Are Object-Oriented Operating Systems?
3.7) What Are The Current Object-Oriented Methodologies?
3.8) What Is The OMG/OMA/ORB/CORBA?
3.9) Why Is Garbage Collection A Good Thing?
3.10) What Can I Do To Teach OO To The Kids?
3.11) What Is Available On Object-Oriented Testing?
3.12) What Distributed Systems Are Available?
3.13) What Is The MVC Framework?
3.14) What is Real-Time?
SECTION 4: COMMONLY ASKED LANGUAGE SPECIFIC QUESTIONS
4.1) What Is Downcasting?
4.2) What Are Virtual Functions?
4.3) Can I Use Multiple-Polymorphism Or Multi-Methods In C++?
4.4) Can I Use Dynamic Inheritance In C++?
ANNOTATED BIBLIOGRAPHY
APPENDIXES
APPENDIX A VIPS
APPENDIX B OBJECT-ORIENTED DATABASES AND VENDORS
APPENDIX C OBJECT-ORIENTED LANGUAGES AND VENDORS
APPENDIX D OBJECT-ORIENTED CASE (OOA/D/P TOOLS) AND VENDORS
APPENDIX E ANONYMOUS FTP SITES
APPENDIX F MAGAZINES, JOURNALS AND NEWSLETTERS
[Another appendix on miscellaneous commercial object-oriented systems should
be added soon for completeness]
SECTION 1: BASICS
==================
Suggested Readings:
[Booch 91, 94]
Others to be added...
1.1) What Is An Object?
-----------------------
There are many definitions of an object, such as found in [Booch 91, p77]:
"An object has state, behavior, and identity; the structure and behavior of
similar objects are defined in their common class; the terms instance and
object are interchangeable". This is a "classical languages" definition, as
defined in [Coplien 92, p280], where "classes play a central role in the
object model", since they do not in prototyping/delegation languages.
"The term object was first formally applied in the Simula language, and
objects typically existed in Simula programs to simulate some aspect of
reality" [Booch 91, p77]. Other definitions referenced by Booch include
Smith and Tockey: "an object represents an individual, identifiable item,
unit, or entity, either real or abstract, with a well-defined role in the
problem domain." and [Cox 91]: "anything with a crisply defined boundary"
(in context, this is "outside the computer domain". A more conventional
definition appears on pg 54). Booch goes on to describe these definitions
in depth. [Martin 92, p 241] defines: "An "object" is anything to which a
concept applies", and "A concept is an idea or notion we share that applies
to certain objects in our awareness". [Rumbaugh 91] defines: "We define an
object as a concept, abstraction or thing with crisp boundaries and meaning for
the problem at hand." [Shlaer 88, p 14] defines: "An object is an abstraction
of a set of real-world things such that:
* all of the real-world things in the set - the instances - have the same
characteristics
* all instances are subject to and conform to the same rules"
and on identifying objects: "What are the *things* in this problem? Most of
the things are likely to fall into the following five categories: Tangible
things, Roles, Incidents, Interactions, and Specifications." [Booch 91, 4.3]
covers "Identifying Key Abstractions" for objects and classes based on an
understanding of the problem domain and [Jacobson 92] provides a novel approach
to identifying objects through use-cases.
The implementation of objects could roughly be categorized into descriptor-
based, capability-based, and simple static-based approaches. Descriptor-
based approaches (e.g. Smalltalk handles) allow powerful dynamic typing, as
do the capability-based approaches which are typically found in object-
oriented databases and operating systems (object id's). A "proxy" based
approach with an added layer of indirection to Smalltalk's handles is found
in Distributed Smalltalk which allows transparent, distributed, and migrating
objects [Kim 89, ch 19 and Yaoqing 93]. Simple static approaches are found
in languages such as C++, although the new RTTI facility will supply simple
dynamic typing, which is also present in new versions of Eiffel.
Descriptor-based approaches can have pointer semantics and can be statically
typeless (or just "typeless", as in Smalltalk) where references (variables)
have no type, but the objects (values) they point to always do. An untyped
pointer (such as void* in C++) and an embedded dynamic typing scheme are used
in more conventional languages to fully emulate this style of dynamically typed
programming (see sections 2.3, 4.3, and [Coplien 92]).
Below is a simple example to show a most trivial case of OO implementation.
It is primarily intended to introduce new terms. See [Cardelli 85] for
another semantic definition of OO using functions for methods and for
a view of types as sets of values.
Simple statically-typed objects (static and auto vars and temps in C++ and
expanded types in Eiffel) can be viewed as instances of a record type,
whose record fields are called instance variables (Smalltalk) or member data
(C++). The record (class) may also contain operations which are called
methods (Smalltalk) or member functions (C++) which are equivalent to a
function taking an object of the record type, called the receiver, as the
first parameter. The receiver is called self (Smalltalk) or this (C++).
Members will denote both instance variables and methods. Inheritance is
roughly equivalent to a loosely coupled variant record, with derived classes
as variant parts and with multiple-inheritance concatenating several records
to serve as a base.
A virtual member in statically typed languages is a base class member that can
be set or respecified by a derived class. This is roughly equivalent to a
pointer or function pointer in the base class being set by the derived class.
[Stroustrup 90] covers the implementation details of virtual member functions
in C++, which also involve an offset for the receiver to handle multiple-
inheritance. This is an example of dynamic binding, which replaces a
switch statement on variant parts with a single call, reducing code size
and program complexity (fewer nested programming constructs) and allowing
variants to be added without modifying client code (which causes higher defect
injection rates during maintanance and debugging).
Virtual members in dynamically typed languages are more flexible because
static typechecking requirements are dropped. See section 2.5.
The terms method/member function, instance variable/member data, subclass/
derived class, parent class/base class, and etc. will be used interchangeably.
As pointed out in [Stroustrup 90, p197], the base/derived class terminology
may be preferable to the sub/super-class terminology, and is preferred in
this document also.
Delegation/prototyping languages [Kim 89, ch3; Ungar 87, Sciore 89] have a more
flexible kind of object which can play the role of classes in classical OO
languages. Since there is no separate class construct in these languages, and
only objects, they are referred to as single-hierarchy, or 1 Level systems.
Objects contain fields, methods and delegates (pseudo parents), whereas
classical object-oriented languages associate method, field and parent
definitions with classes (and only associate state and class with objects,
although vtables of function pointers for dynamic binding is an exception).
However, one-level objects often play the role of classes to take advantage of
sharing and often instances will simply delegate to parents to access methods
or shared state, otherwise idiosyncratic objects, a powerful and natural
concept, will result. Typical 1 Level objects can contain any number of
fields, methods and parents and any object can be used as a template/exemplar,
thus performing the classical role of a class. In typical prototyping systems,
parents (as any other member) can be added or changed dynamically, providing
dynamic multiple inheritance (or more typically simple delegation). Here, the
term "Prototype" usually refers to prototype theory, a recent theory of
classification where any object can be inherited from or cloned to serve as a
prototype for newly created instances. [The Author also uses the term for
languages providing high quality support for rapid prototyping, although this
usage is atypical] See [Booch 94, pp 154-155] for a brief discussion of
prototype theory in the context of OOA and OOD.
It is common in such systems for an object to "become" another kind of object
by changing its parent. A good example is a window becoming an icon, since
window and icon objects display different behavior (although cognitive
differences are significant too:-) Delegation refers to delegating the
search for an attribute to a delegate, and is therefore more of a pure
message passing mechanism (as with dynamic scoping) than inheritance, which
also typically specifies non-shared state when used for representation.
Chambers has proposed an interesting variation called "Predicate Classes"
[Chambers 93] as a part of his Cecil language. These classes will only be
parents when certain predicates are true. This can support a types/classes
as collections of objects view, which is the same as the types as sets of
values view taken by [Cardelli 85]. [Martin 92] provides some examples of
this view applied during OOA.
1 level systems therefore provide the most flexible and powerful capabilities.
Self is a good example of a delegation-based single hierarchy language [Ungar
87].
1.2) What Is Object Encapsulation (Or Protection)?
---------------------------------------------------
[Booch 91, p. 45] defines: "Encapsulation is the process of hiding all of the
details of an object that do not contribute to its essential characteristics."
[Coad 91, 1.1.2] defines: "Encapsulation (Information Hiding). A principle,
used when developing an overall program structure, that each component of a
program should encapsulate or hide a single design decision... The interface
to each module is defined in such a way as to reveal as little as possible
about its inner workings. [Oxford, 1986]"
Some languages permit arbitrary access to objects and allow methods to be
defined outside of a class as in conventional programming. Simula and
Object Pascal provide no protection for objects, meaning instance variables
may be accessed wherever visible. CLOS and Ada allow methods to be defined
outside of a class, providing functions and procedures. While both CLOS
and Ada have packages for encapsulation, CLOS's are optional while Ada's
methodology clearly specifies class-like encapsulation (Adts).
However most object-oriented languages provide a well defined interface to
their objects thru classes. C++ has a very general encapsulation/protection
mechanism with public, private and protected members. Public members (member
data and member functions) may be accessed from anywhere. A Stack's Push and
Pop methods will be public. Private members are only accessible from within
a class. A Stack's representation, such as a list or array, will usually be
private. Protected members are accessible from within a class and also from
within subclasses (also called derived classes). A Stack's representation
could be declared protected allowing subclass access. C++ also allows a
class to specify friends (other (sub)classes and functions), that can access
all members (its representation). Eiffel 3.0 allows exporting access to
specific classes.
For another example, Smalltalk's class instance variables are not accessible
from outside of their class (they are not only private, but invisible).
Smalltalk's methods are all public (can be invoked from anywhere), but a
private specifier indicates methods should not be used from outside of the
class. All Smalltalk instance variables can be accessed by subclasses,
helping with abstract classes and overriding.
Another issue is per-object or per-class protection. Per-class protection
is most common (e.g. Ada, C++, Eiffel), where class methods can access any
object of that class and not just the receiver. Methods can only access the
receiver in per-object protection. This supports a subtyping model, as any
object other than the receiver is only satisfying an abstract type interface,
whereby no method or object structure can be inferred in the general case.
1.3 What Is A Class?
--------------------
A class is a general term denoting classification and also has a new meaning
in object-oriented methods. Within the OO context, a class is a specification
of structure (instance variables), behavior (methods), and inheritance
(parents, or recursive structure and behavior) for objects. As pointed out
above, classes can also specify access permissions for clients and derived
classes, visibility and member lookup resolution. This is a feature-based or
intensional definition, emphasizing a class as a descriptor/constructor of
objects (as opposed to a collection of objects, as with the more classical
extensional view, which may begin the analysis process).
Original Aristotlean classification defines a "class" as a generalization of
objects:
[Booch 91, p93]
"a group, set, or kind marked by common attributes or a common attribute; a
group division, distinction, or rating based on quality, degree of
competence, or condition".
[Booch's definition in the context of OOD]
"A class is a set of objects that share a common structure and a common
behavior." "A single object is simply an instance of a class."
The intension of a class is its semantics and its extension is its instances
[Martin 92].
[Booch 94, 4.2] proposes 3 views of classification as useful in OO analysis and
design: classical categorization (common properties), conceptual clustering
(conceptual descriptions), and prototype theory (resemblance to an exemplar).
He advocates starting with the former approach, turning to the second approach
upon unsatisfactory results, and finally the latter if the first two approaches
fail to suffice.
1.4) What Is A Meta-Class?
---------------------------
[See also section 1.6]
A Meta-Class is a class' class. If a class is an object, then that object
must have a class (in classical OO anyway). Compilers provide an easy way to
picture Meta-Classes. Classes must be implemented in some way; perhaps with
dictionaries for methods, instances, and parents and methods to perform all
the work of being a class. This can be declared in a class named "Meta-Class".
The Meta-Class can also provide services to application programs, such as
returning a set of all methods, instances or parents for review (or even
modification). [Booch 91, p 119] provides another example in Smalltalk with
timers. In Smalltalk, the situation is more complex. To make this easy, refer
to the following listing, which is based on the number of levels of distinct
instantiations:
1 Level System
All objects can be viewed as classes and all classes can be viewed as
objects (as in Self). There is no need for Meta-Classes because objects
describe themselves. Also called "single-hierarchy" systems.
There is only 1 kind of object.
2 Level System
All Objects are instances of a Class but Classes are not accessible to
programs (no Meta-Class except for in the compiler and perhaps for type-safe
linkage, as in C++).
There are 2 kinds of distinct objects: objects and classes.
3 Level System
All objects are instances of a class and all classes are instances of
Meta-Class. The Meta-Class is a class and is therefore an instance of
itself (really making this a 3 1/2 Level System). This allows classes to
be first class objects and therefore classes are available to programs.
There are 2 kinds of distinct objects (objects and classes), with a
distinguished class, the metaclass.
5 Level System
What Smalltalk provides. Like a 3 Level System, but there is an extra level
of specialized Meta-Classes for classes. There is still a Meta-Class as in
a 3 Level System, but as a class it also has a specialized Meta-Class, the
"Meta-Class class" and this results in a 5 Level System:
object
class
class class (Smalltalk's Meta-Classes)
Meta-Class
Meta-Class class
The "class class"es handle messages to classes, such as constructors and
"new", and also "class variables" (a term from Smalltalk), which are
variables shared between all instances of a class (static member data in
C++). There are 3 distinct kinds of objects (objects, classes, and
metaclasses).
1.5) What Is The Infinite Regress Of Objects And Classes?
----------------------------------------------------------
In the authors opinion, a myth. The story goes an object is an instance of a
class (Meta-Object), a class is an instance of a Meta-Class, which must also
be an instance of a Meta-Meta-Class, which must also be an instance of a Meta-
Meta-Meta-Class, ... Closure can be achieved with an instance-of loop, as with
a Meta-Class being an instance of itself or with a "Meta-Class - Meta-Class
class" instance-of loop (as in Smalltalk).
1.6) What Are MOPs And Reflection?
-----------------------------------
MOP is an acronym for Meta-Object Protocol. This is a system with
Meta-Classes accessible to users [Kiczales 92]. In CLOS terminology, an
introspective protocol provides a read only capability (e.g. what is this
object's class, give info on this class, etc.) and an intercessory protocol
provides a write capability which allows system modification (e.g. add the
following method or instance to this class, perform inheritance this way,
etc.). Because inheritance can be used to perform differential changes,
intercessory protocols allow users to not only define new frameworks but
to specialize existing system frameworks differentially without affecting
them and their extant objects. Thus, many frameworks can interoperate
together simultaneously. This is a good example of object-oriented reuse,
since the compiler itself is reused thru specialization to provide new
frameworks.
"Reflective" systems are systems with MOPs (not to be confused with reflexive
systems, which often refer to systems implemented in terms of themselves, or
bootstrapped). Reflective systems are inevitably reflexive (as are most
quality compilers), providing a direct program interface to the system.
1.7) What Is Inheritance?
--------------------------
Inheritance provides a natural classification for kinds of objects and allows
for the commonality of objects to be explicitly taken advantage of in modeling
and constructing object systems. See the example below using computers.
Inheritance is a relationship between classes where one class is the parent
(base/superclass/ancestor/etc.) class of another. Inheritance provides
programming by extension (as opposed to programming by reinvention
[LaLonde 90]) and can be used as an is-a-kind-of (or is-a) relationship or
for differential programming. Inheritance can also double for assignment
compatibility (see section 2.7).
In delegation languages, such as Self, inheritance is delegation where objects
refer to other objects to respond to messages (environment) and do not
respecify state by default.
Inherited parents can specify various flavors of state. Delegation languages
don't specify new state by default (to do so requires cloning), C-based (C++,
Eiffel, Objective-C, etc.), lisp-based (CLOS, Flavors, Scheme, etc.), and
Pascal-based (Ada-9x, Modula-3, Object Pascal, etc.) OO languages do, but with
multiple-inheritance can also share parents within a class lattice (CLOS and
Eiffel provide this as a default at the level of slots and features,
respectively).
Inheritance also provides for member lookup, or internal environment. Various
schemes exist, for example C++ finds the closest match within a scope but
causes an ambiguity error iff more than one parent has match, CLOS creates
a linear precedence list, Self provides parent priorities, and Eiffel forces
renaming for any parent member conflicts.
Defining inheritance (with a thorough description or denotational semantic
definition, or both) can avoid confusion about which inheritance scheme is
being used (especially in OOD), because inheritance has many variations and
combinations of state and environment (sometimes with complex rules).
Inheritance can also be used for typing, where a type or class can be used to
specify required attributes of a matching object (see sections 2.1, 2.7 and
[Cardelli 85]). It would be more judicious to have discussions on how
inheritance should be defined instead of over what it is, since it has many
existing uses and semantics.
An example of the is-a-kind-of relationship is shown below. Is-a is often
used synonymously, but can be used to show the "object is-a class"
instantiation relationship. In classical OO, inheritance is a relationship
between classes only. In one-level systems, is-a (object instantiation) and
is-a-kind-of (inheritance) are merged into one [Ungar 87, Madsen 93, Sciore
89].
Computer
/ | \
Mainframe Mini Personal
/ \ ... / \
Data Proc Scientific PC Workstation
Class hierarchies are subjective [Booch 91, 4.2; Lakoff 87] and usually drawn
with the parent class on top, but more demanding graphs (as is often the case
in [Rumbaugh 91]) allow any topology, with the head of an arrow indicating the
base class and the tail indicating the derived class.
Differential programming is the use of inheritance to reuse existing classes
by making a small change to a class. Creating a subclass to alter a method
or to add a method to a parent class is an example.
1.8) What Is Multiple Inheritance?
-----------------------------------
Multiple Inheritance occurs when a class inherits from more than one parent.
For example, a person is a mammal and an intellectual_entity, and a document
may be an editable_item and a kind of literature.
Mixin's is a style of MI (from flavors) where a class is created to provide
additional attributes or properties to other classes. They are intended to be
inherited by any class requiring them. Method combination, or calling
sequences of before, after, and around methods or even several primary methods
[Kim 89, ch 4], make good use of mixins by invoking their methods without
explicitly calling them, allowing client class code to remain unchanged [Booch
91, p 113].
1.9) Does Multiple Inheritance Pose Any Additional Difficulties?
-----------------------------------------------------------------
Yes, it does. Any name can be simply resolved to a class member with single
inheritance by simply accessing the first name encountered for data members
and by accessing the first signature match (or ambiguity) encountered for
methods (at least one way, C++ hides some member functions). Since several
distinct parents can declare a member within a multiple inheritance hierarchy,
which to choose becomes an issue. Eiffel forces derived classes to rename
parent members that conflict. Self prioritizes parents. CLOS merges member
"slots" (instance variables) with the same name into a single slot, as did
the earlier flavors. C++ declares an error iff a conflict arises, but a
class qualifier can be used to explicitly disambiguate. Smalltalk renders
same names for instance variables of subclasses illegal.
On the other hand, multiple-inheritance can be seen as required for basic
object-oriented programming, because many objects in the real world belong to
several classes. In classical systems without MI, a class which should inherit
from more than one class must textually include all but one of those classes in
its interface, causing code duplication (and a messy interface).
1.10) What Is Dynamic Inheritance?
-----------------------------------
Dynamic inheritance allows objects to change and evolve over time. Since base
classes provide properties and attributes for objects, changing base classes
changes the properties and attributes of a class. A previous example was a
window changing into an icon and then back again, which involves changing a
base class between a window and icon class.
More specifically, dynamic inheritance refers to the ability to add, delete,
or change parents from objects (or classes) at run-time. Actors, CLOS, and
Smalltalk provide dynamic inheritance in some form or other. Single hierarchy
systems, such as Self, provide dynamic inheritance in the form of delegation
[Ungar 87].
See also [Kim 89, chs 1, 3] for a discussion and [Coplien 92] for some
implementation discussion in C++.
1.11) What Is Shared (Repeated) Inheritance?
---------------------------------------------
Multiple Inheritance brings up the possibility for a class to appear as a
parent more than once in a class graph (repeated inheritance), and there is
then a potential to share that class. Only one instance of the class will
then appear in the graph (as is always the case in CLOS, because all *members*
with the same name will be shared (receive a single slot) with the greatest
common subtype as its type). C++ provides an alternative, where only parents
specified as virtual (virtual bases) are shared within the same class lattice,
allowing both shared and non-shared occurrences of a parent to coexist. All
"features" in Eiffel (C++ members) of a repeated parent that are not to be
shared must be renamed "along an inheritance path", else they are shared by
default. This allows a finer granularity of control and consistent name
resolution but requires more work for parents with many features.
1.12) Why Use Inheritance?
---------------------------
Inheritance is a natural way to model the world or a domain of discourse,
and so provides a natural model for OOA and OOD (and even OOP). This is
common in the AI domain, where semantic nets use inheritance to understand
the world by using classes and concepts for generalization and categorization,
by reducing the real-world's inherent complexity.
Inheritance also provides for code and structural reuse. In the above Computer
class diagram, all routines and structure available in class Computer are
available to all subclasses throughout the diagram. All attributes available
in Personal computers are also available to all of its subclasses. This kind
of reuse takes advantage of the is-a-kind-of relationship. Class libraries
also allow reuse between applications, potentially allowing order-of-magnitude
increases in productivity and reductions in defect rates (program errors),
as library classes have already been tested and further use provides further
testing providing even greater reliability.
With differential programming, a class does not have to be modified if it is
close to what's required; a derived class can be created to specialize it.
This avoids code redundancy, since code would have to be copied and modified
otherwise. See [Raj 89] for an alternative approach as found in Jade.
Polymorphism is often explicitly available in many OO languages (such as C++,
CLOS, Eiffel, etc.) based on inheritance when type and class are bound together
(typing based on subclassing, or subclass polymorphism), since only an object
which is a member of (inherits from) a class is polymorphically assignment
compatible with (can be used in place of) instances or references of that
class. Such assignment can result in the loss of an object's dynamic type in
favor of a static type (or even loss of an object's representation to that of
the static class, as in C++ slicing). Maintaining the dynamic type of objects
can be provided (and preferred); however, C++ provides both sliced and non-
sliced replacement in a statically typed environment (see section 2.1).
1.13) Why Don't Some People Like Inheritance?
----------------------------------------------
Some people complain that inheritance is hierarchical (which is what most
object-oriented languages provide). They would also like to see more
operations available (set operations are quite common in specialized systems).
The former is a kind of language dependent feature commonly found in object-
oriented languages which are then associated with the term "inheritance"
(although they don't need to be. For example, delegation languages allow graph
inheritance stuctures). Some don't like the coupling of classes (as in Jade),
but in the author's opinion many of their complaints are easily answered. In
systems that provide inheritance, inheritance provides a simple and elegant way
to reuse code and to model the real world in a meaningful way.
Others complain multiple inheritance is too complicated because it brings up
the issues of shared bases and member conflict resolution. But most modern
systems support Multiple Inheritance by employing semantic resolution
strategies or renaming, and most consider MI to be highly desirable. See the
latter part of section 1.9 for an example of why MI is important.
Some prefer association to MI, claiming "roles" (as defined in [Rumbaugh 91])
should be associations and inheritance should be reserved for a single
hierarchy "creation" mechanism, however this loses polymorphism and loses the
use of inheritance for typical classification. Representation "roles" can be
supported by dynamic multiple inheritance (DMI) in many situations.
1.14) What Is Specialization/Generalization/Overriding?
--------------------------------------------------------
To create a subclass is specialization, to factor out common parts of
derived classes into a common base (or parent) is generalization [Booch 91,
p56]. Overriding is the term used in Smalltalk and C++ for redefining a
(virtual in Simula and C++) method in a derived class, thus providing
specialized behavior. All routines in Smalltalk and Eiffel are overridable
(although in Eiffel they must be "redefined" in a derived class). Whenever
a method is invoked on an object of the base class, the derived class method
is executed overriding the base class method, if any. Overriding in Simula
is a combination of overloading and multiple-polymorphism because parameters do
not have to be declared. Eiffel and Beta are examples of languages allowing
any member to be redefined and not just methods, as is typical.
1.15) What Is The Difference Between Object-Based And Object-Oriented?
-----------------------------------------------------------------------
Object-Based Programming usually refers to objects without inheritance
[Cardelli 85] and hence without polymorphism, as in '83 Ada and Modula-2.
These languages support abstract data types (Adts) and not classes, which
provide inheritance and polymorphism. Ada-9x and Modula-3; however, support
both inheritance and polymorphism and are object-oriented. [Cardelli 85, p481]
state "that a language is object-oriented if and only if it satisfies the
following requirements:
- It supports objects that are data abstractions with an interface of named
operations and a hidden local state.
- Objects have an associated type.
- Types may inherit attributes from supertypes.
object-oriented = data abstractions + object types + type inheritance
These definitions are also found in [Booch 91, Ch2 and Wegner 87].
[Coad 91] provides another model:
Object-Oriented = Classes and Objects
+ Inheritance
+ Communication with messages
Stroustrup's first edition of [Stroustrup 91, '86 p. 37] defines object based
as: "... storing type identification in each object, brings us to a style of
programming often referred to as "object based"", which is quite different
from C+W's.
A more modern definition of "object-oriented" includes single-hierarchy
languages and perhaps object id's for unique objects. Object id's support the
modern notion of relocatable, persistent and distributed objects that can
even migrate across machines. Distributed Smalltalk's proxy objects [Kim 89,
ch 19 and Yaoqing 93] provide another example of a distributable and migratable
object facility. Separate type system support is another extension.
[Booch 94, 2.2] proposes 7 "Elements of the Object Model"; 4 major and 3 minor:
Major:
Abstraction
Encapsulation
Modularity
Hierarchy (Inheritance)
Minor:
Typing
Concurrency
Persistence
1.16) Is A Class An Object?
----------------------------
In C++ no, because C++ classes are not instances of an accessible class (a
Meta-Class) and because C++ classes are not accessible to programs. Classes
are objects in 3 Level Systems and above because classes are instances of
meta-classes. But classes play a dual role, because objects can only be
declared to be instances of a class (and class objects instances of a
meta-class). In 1 Level (single-hierarchy) systems, all classes are objects.
1.17) Is An Object A Class?
----------------------------
In a Level 3 System and above yes, but only instances of a Meta-Class are
Classes. Instances of a Class (ordinary objects) are not classes (excluding
hybrid systems). However, all objects may be classes in single hierarchy
systems, since any object may act as a class (provide object instantiation or
act as a shared parent).
1.18) What Is A Method? (And Receiver And Message)
---------------------------------------------------
A method implements behavior, which is defined by [Booch 91, p80]:
Behavior is how an object acts and reacts, in terms of its state changes
and message passing.
A method is a function or procedure which is defined in a class and typically
can access the internal state of an object of that class to perform some
operation. It can be thought of as a procedure with the first parameter as
the object to work on. This object is called the receiver, which is the object
the method operates on. An exception exists with C++'s static member functions
which do not have a receiver, or "this" pointer. The following are some common
notations for invoking a method, and this invocation can be called a message
(or message passing, see below):
receiver.message_name(a1, a2, a3)
receiver message_name: a1 parm1: a2 parm3: a3
Selector would be another good choice for message_name in the above examples,
although keywords (or formal parameter names, like named parameters) are
considered part of the selector in Smalltalk (and hence Objective-C).
If done statically, this can be referred to as invocation, and message passing
if done dynamically (true dynamic binding). Statically typed dynamic binding
(e.g. C++ and Eiffel) is really in between (checked function pointers).
See also section 1.19 below for a discussion on the functional (prefix) verses
message based (receiver based) notation.
1.19) What Are Multi-Methods And Multiple-Polymorphism?
--------------------------------------------------------
Multi-methods involve two primary concepts, multiple-polymorphism and lack of
encapsulation. These issues are orthogonal. Multiple-polymorphism implies
more than one parameter can be used in the selection of a method. Lack of
encapsulation implies all arguments can be accessed by a multi-method (although
packages can be used to restrict access, as in CLOS). Multi-methods can also
imply a functional prefix notation, although the CLOS designers (who coined the
term "multi-method") consider the functional and receiver based forms
(messages) equivalent. Functional syntax was chosen "in order to minimize the
number of new mechanisms added to COMMON LISP" [Kim ch 4, p70 (D. Moon)].
[Chambers 93] discusses multi-methods in his new OO language, Cecil.
Multiple-polymorphism allows specialized functions or methods to be defined to
handle various cases:
+(int, int)
+(int, float)
+(int, complex)
+(int, real)
+(float, complex)
+(float, real)
+(float, float)
The above functions are specialized to each of the cases required allowing
single, highly cohesive and loosely coupled functions to be defined. This is
also the true essence of object-oriented polymorphism, which allows objects to
define methods for each specific case desired. In addition to better coupling
and cohesion, multiple-polymorphism reduces program complexity by avoiding
coding logic (switch statements) and because small methods further reduce
complexity, as code complexity doesn't grow linearly with lines of code per
method, but perhaps exponentially. This should be distinguished from double
dispatch, a fancy name for single dispatch after a call, which only provides
switching on a single argument per call (but for 2 levels), consistently
ignoring the inherent type of parameters in messaging. Double dispatch is
used in languages with static typing for efficiency considerations.
If all of the above types are Numbers, code can be written without concern for
the actual classes of objects present:
fn(one, two: Number): Number
return one + two;
The addition expression above will invoke the correct "+" function based on the
inherent (true, actual, or dynamic) types of one and two. Only the inherent
type of "one" would be used with double dispatch! In the author's opinion,
this is a serious shortcoming. Further, double dispatch would only allow
switching to the "fn" function based on the type of "one" also. This could
lead to the use of switch statements based on type or complex coding in many
real-world programming situations, unnecessarily. In the author's opinion,
this should only be used as necessary, e.g. if the implementation language
doesn't support multiple-polymorphism and either efficiency considerations
dominate and double dispatch can be suffered, or an embedded dynamic typing
scheme is used.
Why do multi-methods allow open access to parameters? It allows for efficient
handling, like C++ friends, usually by allowing representation details of more
than one object to be exposed. See [Kim ch 4, pp70-71 (D. Moon)] for an
alternative explanation. While open access can be useful in some cases, it
typically isn't recommended as a general OO practise (see section 1.15, C+W's
requirement 1 for OO languages) and also violates subtype polymorphism, because
only subclass polymorphism is based on representation and not type.
Polymorphic languages can be statically typed to provide strong type checking,
efficiency, and to support a static programming idiom, but require restrictions
in many cases, such as requiring overriding methods to have identical
signatures with the methods they substitute (as in C++) or allowing covariant
parameters but limiting base class usage (as in Eiffel). If these restrictions
are dropped, multiple-polymorphism results. Thus a single overridable function
declared in a base class may have several functions overriding it in a derived
class differentiated only by their formal argument types. This therefore
requires both static and dynamic typing, because no formal argument
differentiation is possible without static types, as in Smalltalk, and no
actual argument differentiation is possible without dynamic types (as in C++
and Eiffel). See section 2.3 for another example of multiple-polymorphism.
There is some concern about the efficiency of run-time method selection as
can occur with multiple-polymorphism (or even dynamic message passing).
However, static analysis optimizations are commonly available in the
literature, potentially providing a single static selection in many cases
[See Agrawal 91, Chambers 92, Mugridge 91, and etc.].
But coupling the two cases of selector variables (as found in CLOS,
Objective-C, and etc.) and several possible known selectors together with the
general undecidability of dynamic types at compile-time renders dynamic typing
and run-time selection (or checking) as unavoidable in the general case [a
point often mistaken in comp.object. E.g. simple statically/strongly typed
multi-methods still require dynamic types!]
See [Booch 91], multiple-polymorphism, for a good CLOS example.
1.20) What Is OOP?
-------------------
OOP stands for Object-Oriented Programming, the usual programming/hacking and
etc. most programmers think of. Modern software engineering methodologies;
however, consider OOP as the implementation/evolution of an OOD.
1.21) What Is OOA/OOD (And Where Can I Get What I Need On It)?
---------------------------------------------------------------
See also section 3.7, the Annotated Bibliography, and APPENDIX D. The
classified bibliography in [Booch 94] also contains entries on OOA(B), OOD(F)
and OOP(G).
[Booch 91]
"In OOA, we seek to model the world by identifying the classes and objects
that form the vocabulary of the problem domain, and in OOD, we invent the
abstractions and mechanisms that provide the behavior that this model
requires."
[Coad 91]
"OOA is the challenge of understanding the problem domain, and then the
system's responsibilities in that light".
"To us, analysis is the study of a problem domain, leading to a specification
of externally observable behavior; a complete, consistent, and feasible
statement of what is needed; a coverage of both functional and quantified
operational characteristics (e.g. reliability, availability, performance)".
"Design. The practise of taking a specification of externally available
behavior and adding details needed for actual computer system implementation,
including human interaction, task management, and data management details."
And on Domain Analysis:
"Whereas OOA typically focuses upon one specific problem at a time, domain
analysis seeks to identify the classes and objects that are common to all
applications within a given domain, [...]". - [Booch 91]
[The following quotes on domain analysis are from [Berard 93]]
"An investigation of a specific application area that seeks to identify the
operations, objects, and structures that commonly occur in software systems
within this area. - Dan McNicholl
"Systems analysis states what is done for a specific problem in a domain
while domain analysis states what can be done in a range of problems in a
domain. ...A domain analysis is only useful in many similar systems are to
be built so that the cost of the domain analysis can be amortized over the
cost of all the systems.
The key to reusable software is captured in domain analysis in that it
stresses the reusability of analysis and design, not code. - Jim Neighbors
"The process of identifying, collecting, organizing, and representing the
relevant information in a domain based on the study of existing systems and
their development histories, knowledge captured from domain experts,
underlying theory, and emerging technology within the domain." - Kang et al.
Object-oriented domain analysis (OODA) seeks to identify reusable items
localized around objects, e.g., classes, instances, systems of interacting
objects, and kits [frameworks]. OORA analysts and OOD designers will
interact on a fairly frequent basis with the domain analysis effort.
OOA and OOD stand for Object-Oriented Analysis and Object-Oriented Design,
respectively. OOA strives to understand and model, in terms of object-oriented
concepts (objects and classes), a particular problem within a problem domain
(from its requirements, domain and environment) from a user-oriented or domain
expert's perspective and with an emphasis on modeling the real-world (the
system and its context/(user-)environment). The product, or resultant model,
of OOA specifies a complete system and a complete set of requirements and
external interface of the system to be built.
[Shlaer 88] is often credited as the first book on OOA, although their method
adds OO techniques to the traditional structured analysis principles of Yourdon
and Constantine. Their complete approach ([Shlaer 88, 92]) consists of
information modeling and recursive design, or OOA/RD and represents a recent
addition to the structured analysis family (as does Martin and Odell).
[Yourdon 92] provides a critique, although may only refer to their earlier
work. Many other methodologies including Rumbaugh's OMT, Martin and Odell's
OOA/D, and many others, also share common ground with SA and other existing
analysis methodologies with such constructs as associations (E-R), functional
models, and even DFD's. Booch, Jacobson, and Wirfs-Brock are examples of OO
methodologies representing a greater departure from the conventional
"structured" techniques, with greater emphasis on objects. OOram [Reenskaug
91] provides support and emphasis on types and roles as guiding principles,
which is quite powerful. [Booch 94] presents a methodology which is an
evolutionary step beyond the first edition by incorporating a collection of the
best features from several of the major OO methodologies, as does HP's new
FUSION methodology.
The usual progression is from OOA to OOD to OOP (implementation) and this
Universal Process Model roughly corresponds to the Waterfall Model [Royce 70].
See [Humphrey 89] and [Yourdon 92] for a few of many discussions on software
life-cycle models and their use. Humphrey also details Worldy and Atomic
Process Models for finer grained analysis and design in the Defined Process
(see below) and discusses other alternatives to the task oriented models. He
also provides the following critisisms on the Waterfall Model which had led to
Boehm's seminal work on the Spiral Model:
* It does not adequately address changes
* It assumes a relatively uniform and orderly sequence of development steps
* It does not provide for such methods as rapid prototyping or advanced
languages
Modern OO methodologies directly address these points and emphasize the
incremental, iterative, evolutionary, concurrent and situational nature of
software development. [Boehm 86] presents a seminal spiral life-cycle model
with a risk-driven prototyping approach. [Booch 91, 6.1] proposes a "round-
trip gestalt" design with analyze-design iterations and an overall system
perspective and [Berard 93] proposes an (incremental) "parallel-recursive
design" with analyze-design-implement-test iterations. [Coad 91b] presents
the following development cycle breakdown:
Waterfall-
Analysis
Design
Programming
Spiral-
Analysis, prototyping, risk management
Design, prototyping, risk management
Programming, prototyping, risk management
[Boehm, 1988]
Incremental-
A little analysis
A little design
A little programming
Repeat
[Gilb, 1988]
[Author's note: The spiral model may be incremental in many ways and ends with
a waterfall.]
Since classes and objects are used in all phases of the OO software life-cycle,
the process is often referred to as seamless, meaning there is no conceptual
gap between the phases as is often the case in other software development
methodologies, such as the analysis (DFD's) to design (structure charts) to
programming gaps found in traditional structured analysis and design.
Seamlessness together with naturalness is a big advantage for consistency.
A problem domain has many realizations, or differing OOAs. An OOA has many
realizations, or differing OODs, but a similar notation is often used for
the two. An OOD also has many realizations, or differing OOPs, but allows a
selection from among various languages for implementation (choosing the best
language to implement the design). But some, such as Bjarne Stroustrup, don't
like OOA and OOD getting too far from OOP (implementation independent), for
fear that great discrepancies could occur between OOD and OOP by losing sight
of the implementation language, which in some cases is predetermined. See also
[Stroustrup 91].
From a greater perspective, the SEI has developed the Software Process Maturity
Model (SPMM), a 5 level model classifying the progressive levels of an
organization's software development [Humphrey 89].
Level 1: Initial: Every project is handled differently
Level 2: Repeatable: Every project is handled similarly
Level 3: Defined: A standard process is now well defined for all projects
Level 4: Managed: A measurable basis for all improvements to the process
Level 5: Optimizing: Emphasis on defect prevention and optimizing/continually
improving the process
See also [Yourdon 92], [Wilkie 93], and [Booch 94] for discussions on this
often cited model. There is also an ISO 9000 standard on software quality.
Object-Oriented Information Engineering's "Enterprise Modeling" [Martin 92],
also found in [Jacobson 92], and some recent business "reengineering" efforts
place information systems within an organizational perspective by modeling
entire organizations or a large part of them, with the information processing
system and software products development as integrated components. [Yourdon
92] even calls for "global modeling"!
1.22) Where Did Object-Orientation Come From?
----------------------------------------------
Simula was the first object-oriented language providing objects, classes,
inheritance, and dynamic typing in 1967 (in addition to its Algol-60 subset).
It was intended as a conveyance of object-oriented design. Simula 1 was a
simulation language, and the later general-purpose language Simula 67 is now
referred to as simply Simula. Smalltalk was the next major contributor
including classes, inheritance, a high-powered graphical environment and a
powerful dynamic typing mechanism (although these existed to some extent in
Simula). Self is somewhat of a Smalltalk-based next generation language, as is
Beta a followup to Simula (by its original designers).
[Meyer 88] contains a brief summary and history of Simula and Smalltalk, among
other OO languages.
1.23) What Are The Benefits Of Object-Orientation?
---------------------------------------------------
Reuse, quality, an emphasis on modeling the real world (or a "stronger
equivalence" with the RW than other methodologies), a consistent and seamless
OOA/OOD/OOP package, naturalness (our "object concept") and etc.
[Harmon 93]:
Faster development
Increased Quality
Easier maintenance
Enhanced modifiability
[Booch 94]:
Exploit power of OOPs
Reuse of software and designs, frameworks
Systems more change resilient, evolvable
Reduced development risks for complex systems, integration spread out
Appeals to human cognition, naturalness
1.24) What Other FAQs Are Available?
-------------------------------------
FAQ's are cross-posted to news.answers and are archived on anonymous ftp from:
rtfm.mit.edu:/pub/usenet (also usenet-by-hierarchy, etc.)
rtfm archives several FAQs pertinent to OO (most are also archived elsewhere):
comp.lang.ada ajpo.sei.cmu.edu:public/comp-lang-ada/cla-faq[12]
comp.lang.c++ sun.soe.clarkson.edu:pub/C++/FAQ [128.153.12.3]
comp.lang.clos
comp.lang.eiffel ftp.cm.cf.ac.uk:/pub/eiffel/eiffel-faq
comp.lang.oberon
comp.lang.objective-c
comp.lang.sather ftp.ICSI.Berkeley.EDU:pub/sather [not on rtfm]
comp.lang.scheme ftp.think.com:/public/think/lisp/scheme-faq.text
comp.lang.smalltalk xcf.Berkeley.EDU:misc/smalltalk/FAQ/SmalltalkFAQ.entire
comp.object zaphod.uchicago.edu:/pub/comp.object-faq.1.0.5(.Z)
comp.object.logic ftp.cs.cmu.edu:*prg_1.faq,prg_2.faq [128.2.206.173]
comp.software-eng
[xcf.Berkeley.EDU is 128.32.138.1]
* /afs/cs.cmu.edu/project/ai-repository/ai/pubs/faqs/prolog/
A new C++ libraries FAQ is posted monthly to comp.lang.c++ and should be on
rtfm soon. Contact cpplibs@trmphrst.demon.co.uk. It contains anonymous ftp
sites and commercial libraries and may be merged with this FAQ soon.
Many FAQs are also available from mail-servers, however most can be accessed by
the rtfm mail-server. Mail to mail-server@rtfm.mit.edu with help and index in
the body with no leading spaces and on separate lines for more information.
Example Unix Command (will retrieve this FAQ in about 26 pieces (and growing)):
mail mail-server@rtfm.mit.edu
Subject:
send usenet/comp.object/*
There is also a great ftp site for sci.virtual-worlds on:
stein.u.washington.edu (140.142.56.1)
- home of sci.virtual-worlds, huge faq w/ great info!
- if unable to use try ftp.u.washington.edu
/public/virtual-worlds
[While vr may not be directly related to comp.object, it is most interesting!
- The Author]
SECTION 2: TYPING
==================
There are many definitions of type (and class and related concepts). Many
authors define the terms as applied by their particular approach or language,
however we shall proceed in the face of this diversity.
References
[Blair 89] Some typing topics.
[Booch 91] Small Section on Typing.
[Cardelli 85] Discussion on Object-Oriented Typing.
[Kim 89, ch1] Discussion on Some Research Topics.
2.1) What Is Polymorphism?
---------------------------
Polymorphism is a ubiquitous concept in object-oriented programming and is
defined in many ways, so many definitions are presented from: Websters',
Author, Strachey, Cardelli and Wegner, Booch, Meyer, Stroustrup, and Rumbaugh.
Polymorphism is often considered the most powerful facility of an OOPL.
> Webster's New World Dictionary:
Polymorphism 1. State or condition of being polymorphous. 2. Cryall.
crystallization into 2 or more chemically identical but
crystallographically distinct forms. 3. Zool., Bot. existence of an
animal or plant in several forms or color varieties.
polymorphous adj. having, assuming, or passing through many or various forms,
stages, or the like. Also, polymorphic. [<Gk polymorphous multiform]
> Author's Definition:
Polymorphism is the ability of an object (or reference) to assume (be replaced
by) or become many different forms of object. Inheritance (or delegation)
specifies slightly different or additional structure or behavior for an object,
and these more specific or additional attributes of an object of a base class
(or type) when assuming or becoming an object of a derived class characterizes
object-oriented polymorphism. This is a special case of parametric
polymorphism, which allows an object (or reference) to assume or become any
object (possibly satisfying some implicit or explicit type constraints
(parametric type), or a common structure), with this common structure being
provided by base classes or types (subclass and subtype polymorphism,
respectively).
"Poly" means "many" and "morph" means "form". The homograph polymorphism has
many uses in the sciences, all referring to objects that can take on or assume
many different forms. Computer Science refers to Strachey's original
definitions of polymorphism, as divided into two major forms, parametric and
ad-hoc. Cardelli and Wegner followup with another classification scheme,
adding inclusion polymorphism for subtyping and inheritance.
> Strachey's Original Definition [Strachey 67]:
"Parametric polymorphism is obtained when a function works uniformly on a range
of types; these types normally exhibit some common structure. Ad-hoc
polymorphism is obtained when a function works, or appears to work, on several
different types (which may not exhibit a common structure) and may behave in
unrelated ways for each type."
Parametric polymorphism is also referred to as "true" polymorphism, whereas
ad-hoc polymorphism isn't (apparent polymorphism).
> Cardelli and Wegner's Definition [Cardelli 85]:
C+W refine Strachey's definition by adding "inclusion polymorphism" to model
subtypes and subclasses (inheritance). Strachey's parametric polymorphism is
divided into parametric and inclusion polymorphism, which are closely related,
but separated to draw a clear distinction between the two forms, which are then
joined as specializations of the new "Universal" polymorphism.
|-- parametric
|-- universal --|
| |-- inclusion
polymorphism --|
| |-- overloading
|-- ad hoc --|
|-- coercion
Polymorphic Languages: some values and variables may have more than one type.
Polymorphic Functions: functions whose operands (actual parameters) can
have more than one type. [...] If we consider a generic function to be
a value, it has many functional types and is therefore polymorphic.
Polymorphic Types: types whose operations are applicable to operands of more
than one type.
Parametric Polymorphism: a polymorphic function has an implicit or explicit
type parameter which determines the type of the argument for each
application of that function.
Inclusion Polymorphism: an object can be viewed as belonging to many different
classes that need not be disjoint; that is, there may be inclusion of
classes.
The two forms of "Universal Polymorphism", parametric and inclusion are closely
related, but are distinct enough in implementation to justify separate
classifications.
Parametric polymorphism is referred to as generics. Generics can be syntactic,
where each instantiation creates a specialized version of the code allowing
fast running execution, but in a "true polymorphic system", only a single
implementation is used.
On inheritance is subtype polymorphism:
"Subtyping on record types corresponds to the concept of inheritance
(subclass) in languages, especially if records are allowed to have functional
components."
Author's Notes:
Implicit parametric polymorphism can be implemented with type inferencing
schemes [Aho 85]. ML is prototypical in providing this facility.
Inclusion polymorphism is common and is found in languages such as Simula,
Ada-9x, C++, CLOS, Eiffel and etc. (subclass polymorphism). Smalltalk also
uses inclusion polymorphism; its used in declaring classes, and subclass
polymorphism is used in practice but not enforced. For inheritance, inclusion
polymorphism specifies an instance of a subclass can appear wherever an
instance of a superclass is required. For subtyping (subtype polymorphism),
the same applies because all operations required by the supertype are present
in the subtype (subtype is subset of supertype). Cardelli and Wegner view
classes as sets of objects (resulting in subtype objects are a subset of
supertype objects, or an extentional view), as contrasted with a feature based
(intentional) approach (where subtypes are supersets of (contain) supertypes).
MI provides an interesting example here, as it is set intersection with an
extensional view and set union with an intentional view. Details are left as
an exercise for the reader.
Ada generics and C++ templates provide explicit syntactic generics. While
Ada may infer some actual generic parameters (operations) and C++ doesn't
require explicit instantiation of its template functions, formal generic
parameters must still be declared and many bodies are generated.
Inclusion polymorphism can refer to subtyping, or having at least as much or
more than required. Since derived classes can inherit structure and behavior
from base classes, such inheritance is an example of inclusion polymorphism
with respect to representation (subclassing). An example of inclusion
polymorphism with respect to assignment (and initialization, or replacement if
viewed in an almost symbolic way) occurs when object types may be specified and
assignment is based on actual object membership in that type (often of the CLOS
is-a-member-of form in OO). Emerald provides another example of an object-
oriented language using inclusion polymorphism with respect to replacement;
however, inclusion is with respect to subtyping only with abstract types
("bounded quantification" by C+W. C+W's parameters are subtype polymorphic
but lose the inherent type). Any object possessing all required operations is
acceptable and no inheritance relation is required (subtype polymorphism).
They refer to this as "best-fitting" types [Black 86]. The original Trellis/
Owl also had such a facility but with two separate inheritance hierarchies,
although it was abandoned in favor of a single class-based approach for
simplicity. See also section 2.7.
[As inclusion polymorphism covers both subtype and subclass polymorphism,
perhaps IP could be further divided in C+W's above classification.]
> Booch's Definition [Booch 91, p. 517]:
polymorphism A concept in type theory, according to which a name (such as a
variable declaration) may denote objects of many different classes that are
related by some common superclass; thus, any object denoted by this name is
able to respond to some common set of operations in different ways.
Booch also has several sections devoted to polymorphism.
[The author notes Booch's definition above is clearly in the context of
conventional, classical OO and subclass polymorphism.]
> Meyer's Definition [Meyer 88, sect. 10.1.5 Polymorphism]:
"Polymorphism" means the ability to take several forms. In object-oriented
programming, this refers to the ability of an entity to refer at run-time to
instances of various classes. In a typed environment such as Eiffel, this is
constrained by inheritance: ...
[The Author notes Meyer has a following section 10.1.7 on Static Type,
dynamic type, which is relevant, but claims "... there is no way the type
of an object can ever change. Only a reference can be polymorphic: ...".
Meyer is clear between the concept and the Eiffel realization in his
polymorphism definition above, but here neglects the "becomes" facility
as found in several dynamically typed OO languages such as Actors, CLOS,
Self and Smalltalk, which allows an object (and not just a reference) to
change its class.]
> Stroustrup's Definition [Stroustrup 90, p. 209]:
The use of derived classes and virtual functions is often called "object-
oriented programming". Furthermore, the ability to call a variety of
functions using exactly the same interface - as is provided by virtual
functions - is sometimes called "polymorphism".
[The Author notes this is a functional view of polymorphism (as provided in
C++). [Stroustrup 91, p. 136] has an example of polymorphism with void *'s,
but a newer template function is incomparably preferable, as implied in
[Stroustrup 90, ch 14]]
Rumbaugh's Definition [Rumbaugh 91, p. 2]:
"Polymorphism" means that the same operation may behave differently on
different classes.
2.2) What Does Polymorphism Boil Down To In OO Programming Languages?
----------------------------------------------------------------------
In C++, virtual functions provide polymorphism. This is because a polymorphic
object (pointer or reference (or such parameter)) is assignment compatible with
any object of a derived class. Is this polymorphism in itself? Objects
can take on objects of different forms (the derived classes), but of what use
is it? To make any difference, the differing forms must have some effect. In
dynamically typed languages, polymorphic objects are passed messages and will
respond in whatever way the object has defined (usually starting from its most
derived class and working its way up). But for static objects, a virtual
function is invoked. This is the stored method from the derived class that
overrode the virtual method from its base class, providing specialized behavior
for the polymorphic object; and hence, polymorphism. This common pure
statically typed example is, of course, an example of inclusion polymorphism,
subclass polymorphism to be more specific (see section 2.1). Pure statically
typed subtype polymorphism, as provided in Emerald, can be implemented
similarly [Black 86].
2.3) What Is Dynamic Binding?
------------------------------
Dynamic binding has two forms, static and dynamic. Statically-typed dynamic
binding is found in languages such as C++ (virtual functions) and Eiffel
(redefinition). It is not known which function will be called for a virtual
function at run-time because a derived class may override the function, in
which case the overriding function must be called. Statically determining all
possibilities of usage is undecidable. When the complete program is compiled,
all such functions are resolved (statically) for actual objects. Formal object
usage must have a consistent way of accessing these functions, as achieved thru
vtables of function pointers in the actual objects (C++) or equivalent,
providing statically-typed dynamic binding (this is really just defining simple
function pointers with static typechecking in the base class, and filling them
in in the derived class, along with offsets to reset the receiver).
The run-time selection of methods is another case of dynamic binding, meaning
lookup is performed (bound) at run-time (dynamically). This is often desired
and even required in many applications including databases, distributed
programming and user interaction (e.g. GUIs). Examples can be found in
[Garfinkel 93, p80] and [Cox 91, pp 64-67]. To extend Garfinkels example with
multiple-polymorphism, a cut operation in an Edit submenu may pass the cut
operation (along with parameters) to any object on the desktop, each of which
handles the message in its own way (OO). If an (application) object can cut
many kinds of objects such as text and graphical objects, multiple-polymorphism
comes into play, as many overloaded cut methods, one per type of object to be
cut, are available in the receiving object, the particular method being
selected based on the actual type of object being cut (which in the GUI case is
not available until run-time).
Again, various optimizations exist for dynamic lookup to increase efficiency
(such as found in [Agrawal 91] and [Chambers 92]).
Dynamic binding allows new objects and code to be interfaced with or added to
a system without affecting existing code and eliminates switch statements.
This removes the spread of knowledge of specific classes throughout a system,
as each object knows what operation to support. It also allows a reduction in
program complexity by replacing a nested construct (switch statement) with a
simple call. It also allows small packages of behavior, improving coherence
and loose coupling. Another benefit is that code complexity increases not
linearly but exponentially with lines of code, so that packaging code into
methods reduces program complexity considerably, even further that removing
the nested switch statement! [Martin 92] covers some of these issues.
2.4) Is There A Difference Between Being A Member Or Instance Of A Class?
--------------------------------------------------------------------------
Yes (but be careful of context). To use C++ terminology, an object (not
a reference) is defined to be an instance of exactly one class (in classical
OO), called its most derived class. An object not directly contained in any
other is called the complete object [Stroustrup 90]. An object is a member
of several classes, including all of the classes its declared (or most derived)
class inherits from. With static typing and inclusion polymorphism based on
class, if a polymorphic object (or reference) is made to refer to an object,
that object must be a member of the polymorphic object's class.
This also provides a good example of differing definitions among object-
oriented languages, since a member is defined as above in CLOS, but a member of
a class is one of its instance variables in C++.
2.5) What Is The Difference Between Static And Dynamic Typing?
---------------------------------------------------------------
Static typing refers to types declared in a program at compile-time, so no type
information is available on objects at run-time. Dynamic typing uses the
inherent types of polymorphic objects, keeping track of the types of objects at
run-time. Statically typed dynamic binding is a compromise (usually
implemented with tables of function pointers and offsets), and is how
statically-typed OO languages provide polymorphism. Some approaches provide
both static and dynamic typing, sometimes with static typing providing type-
safe programs and dynamic typing providing multiple-polymorphism [Agrawal 91]
[Mugridge 91]. See also section 2.3.
Static typing is more efficient and reliable, but loses power. Typical
restrictions include only allowing a common set of base class functions (or
any common functions for the more general subtyping or parametric polymorphic
cases) to be available on formal objects and a lack of multiple-polymorphism
(see section 1.19), both of which are overcome with dynamic typing.
Many languages provide dynamic typing: Smalltalk, Self, Objective-C, and etc.
A limited dynamic typing scheme, called RTTI (Run Time Type Identification),
is even being considered for the C++ standard. A similar facility to safe
downcasting (historically known as type narrowing), the thrust of RTTI, can
also be found in recent versions of Eiffel.
See section 3.4 for a categorization of common OO languages by type system.
2.6) What Is This I Hear About ML And Functional Programming Languages?
------------------------------------------------------------------------
ML, Metalanguage, is a functional programming language with a strongly typed
polymorphic type system [Wikstrom 87]. Russell (see Appendix E) is a more
recent functional language and Haskell [Hudak 92] provides a more modern and
"pure" example. Section 2.5 discusses why static typing has less power/
flexibility than dynamic typing and the same applies to ML (although see the
appendixes for an experimental dynamic extension to ML, Alcool-90 and [Cardelli
85] for a proper placement of ML's type system). ML doesn't use inheritance
for polymorphism; unlike OO languages, but provides the prototypical example of
parametric polymorphism, so no inheritance is required. This is "true" or
"pure" statically (or strongly) checked parametric polymorphism, by Strachey's
(and Cardelli and Wegner's) definitions.
Smalltalk is an example of a dynamically-typed language which does not check
types during assignment (and hence for parameters) and therefore provides
parametric polymorphism without static constraints (by Strachey's definition).
However, Smalltalk's style uses inclusion polymorphism in practise and
inheritance for subclassing (representation).
2.7) What Is A Separation Between Type And Class (Representation)?
-------------------------------------------------------------------
For a short answer:
Subtype Polymorphism, as opposed to Subclass Polymorphism, is the best answer
in OO. Parametric polymorphism is a related concept where this is also true,
but is of a different flavor (and usually requires object attributes by use.
See also section 2.1).
A type can be considered a set of values and a set of operations on those
values. This can insure type-safe programming. However, the representation of
types (classes in OO) can be separated from the notion of type allowing many
representations per type while still maintaining reasonable type-safety.
In many languages, a type has a single representation insuring all operations
performed on that type are well defined (statically bound) and providing for
efficiency by taking advantage of that representation wherever used. In many
OO languages, subclassing and dynamic binding provides for greater flexibility
by providing object specialization. However, in many OO languages classes are
used for assignment compatibility forcing an assigned object to inherit
(transitively) from any polymorphic object's class (inclusion polymorphism
based on class, or subclass polymorphism). This insures all operations to be
performed on any polymorphic object are satisfied by any replacing objects.
This also insures all types share a common representation, or at least a
common base interface specification.
By separating type from class, or representation (or perhaps separating class
from type, by the aforementioned definition of type), a replacing object must
satisfy the operations or type constraints of a polymorphic object (subtype
polymorphism) but are not required to do to do so by an inheritance relation
(subclass polymorphism), as is typical in most OOPLs. Dropping this
restriction is somewhat less type-safe, because accidental matches of method
signatures can occur, calling for greater care in use. [Black 86] discusses
this issue in Emerald. The same issue arises in parametric polymorphism
(generics/templates), as any method matching a required signature is accepted,
calling for careful matching of actual and formal generic parameters. The
difference between static and dynamic binding in OO and dynamic binding and
subtyping seems similar. A possible loss of semantic integrity/similarity is
contrasted with greater power.
It is possible to specify desired abstract properties of type specifications
with mechanisms similar to Eiffel's pre-, post-, and invariant conditions.
This helps to insure the semantic integrity of replacing objects and their
behavior. [Liskov 93] provides a recent exposition.
Abstract classes ([Stroustrup 91] and [Meyer 88]) in typing provide a facility
similar to subtype polymorphism; however, ACs require type compatible classes
to inherit from them, providing a subclass polymorphism facility, and ACs can
also specify representation. Subtyping is therefore most useful to avoid
spreading knowledge of classes throughout a system, which is a high priority
for loosely coupled modules and in distributed programming [Black 87].
The formal type system found in [Cardelli 85], Emerald/Jade [Black 86] and
[Raj 89], original trellis/Owl, an experimental C++ extension (See Appendix E,
Signatures), Sather (Eiffel-based), and an Eiffel superset [Jones 92] are all
examples of OO systems providing subtype polymorphism. Functional languages
such as ML, Russell, and Haskell provide a separation with pure parametric
polymorphism (as is also commonly found in OO languages in additon to inclusion
polymorphism).
2.8) What Are Generics And Templates?
--------------------------------------
Short Answer: Parametric Polymorphism (although various implementations
provide various subsets).
Generics (or Templates in C++) refer to the ability to parameterize types
and functions with types. This is useful for parameterized classes and
polymorphic functions as found in languages such as Ada, C++, Eiffel, and
etc., although these are "syntactic" or restricted forms [Cardelli 85].
Generics are orthogonal to inheritance, since types (and classes)
may be generically parameterized. Generics provide for reusability in
programming languages. An example is a Stack with a generically
parameterized base type. This allows a single Stack class to provide
many instantiations such as a Stack of ints, a Stack of any fundamental
or user defined type, or even a Stack of Stacks of ... Another example is
a polymorphic sort function taking a base type with a comparison operator.
The function can be called with any type (containing a comparison operator).
See [Booch 87b] for several examples in Ada and [Stroustrup xx] and [Murray
93] for examples in C++.
While generics have many advantages, typical limitations include a static
nature, which is an advantage for strong typechecking but a potential
disadvantage when causing dynamic compilation (leading to a time/space
efficiency tradeoff), and sources can cause inlining and create source code
dependencies and expand code size (unlike a single-body or "true"
parametrically polymorphic implementation. Generics can also be viewed as a
special case of type variables.
Functions are typically generic in statically-typed parametrically-polymorphic
languages. One such popular functional language is ML, in which all functions
are generic. Russell and Haskel are more modern variants (references are
forthcoming, however see APPENDIX E).
SECTION 3: GENERAL
===================
References: (many more are to come)
[Coplien 92] Covers C++, symbolic, exemplar (single-hierarchy), etc.
[Kim 89] Covers many OO systems.
3.1) What Is The "Classical" Object-Oriented Paradigm?
-------------------------------------------------------
This refers to the usual class and object model. Its any 2+ level system
as described in section 1.4. See also [Coplien 92].
3.2) What Is The "Delegation/Prototyping" Object-Oriented Paradigm?
--------------------------------------------------------------------
See [Kim 89, ch 1,3].
This is the 1 Level System as Described under Meta-Classes. Delegation refers
to the delegating of responsibility and can be applied to inheritance. When a
derived class does not have a desired attribute, it "delegates" responsibility
to one of its base classes. In delegation systems, each object has a delegate
list instead of a parent list. Thus, delegation's primary emphasis is
on message passing where an object could delegate responsibility of a message
it couldn't handle to objects that potentially could (its delegates). Any
object can be added to the delegate list, giving dynamic inheritance (of a
sort). Typically, delegation and prototyping languages also have "part
inheritance" in which fields and methods can be added and deleted from objects.
This makes for easy "prototyping", which allows for objects to be constructed
piece by piece at run-time, although the term "prototyping" in the context of
delegation languages usually refers to objects serving as prototypes for
object instantiation, or exemplars.
Next's NextStep OS provides delegation as an add-On to Objective-C, providing
an example of delegation in a class-based language [Garfinkel 93].
3.3) Are There Any Other Object-Oriented Paradigms?
----------------------------------------------------
There are many alternatives in OO. Emerald/Jade ([Black 86] and [Raj 89])
provides one, where inheritance is replaced with a roughly equivalent form
where reuse occurs at a finer degree of granularity - method and instance
variables - with subtype polymorphism making up the difference.
CLOS [Kim 89, ch 4] has a looser coupling of methods to classes and doesn't
distinguish a receiver, but packages can help make up the difference.
Object Specialization [Sciore 89] is an example of a hybrid approach between
delegation and classical systems, where parent classes have an extra level
of indirection and inheritance hierarchies are specified on a per object/class
basis.
3.4) What Are The Major Object-Oriented Programming Languages Today?
---------------------------------------------------------------------
Statically-Typed:
Add 1 To Cobol giving Cobol with Objects.
Beta
C++
Classic-Ada
Dragoon
Emerald/Jade
Object Pascal
Trellis/Owl
Dynamically-Typed:
Actors Languages
Flavors
Self
Smalltalk
Both:
Actor
Ada-9x
C++ (With RTTI)
Cecil
CLOS
Eiffel
Modula-3
Objective-C
Sather
3.5) What Are Object-Oriented Databases And Persistence?
---------------------------------------------------------
See also Appendices B and E and the comp.database.object newsgroup.
Refs to be included in future FAQs.
Object-Oriented Databases are databases that support objects and classes. They
are different from the more traditional relational databases because they allow
structured subobjects, each object has its own identity, or object-id (as
opposed to a purely value-oriented approach) and because of support for methods
and inheritance. It is also possible to provide relational operations on an
object-oriented database. OODBs allow all the benefits of object-orientation,
as well as the ability to have a strong equivalence with object-oriented
programs, an equivalence that would be lost if an alternative were chosen, as
with a purely relational database.
Another way of looking at Object-Oriented Databases is as a persistent object
store with a DBMS.
Persistence is often defined as objects (and their classes in the case of
OODBs) that outlive the programs that create them. Object lifetimes can be
viewed as a hierarchy, with locals/automatics having the shortest default
lifetime and objects stored indefinitely in an OODB (which are persistent)
having the longest. Persistent object stores do not support query or
interactive user interface facilities, as found in a fully supported OODBMS.
Appendix B also contains references for relational interfaces to OODBs.
3.6) What Are Object-Oriented Operating Systems?
-------------------------------------------------
Refs to be included in future FAQs. See also Appendix E.
Object-Oriented Operating Systems provide resources through objects, sometimes
all the way down to to the machine (OO architectures are found at the bottom).
They are almost always distributed systems (DOS or DPOS), allowing objects to
be passed freely between machines. They are typically capability-based since
objects, and hence system resources, can only be accessed if a capability to
them is available to programs.
Here are some abstracts taken from several postings to the net. This list is
by no means exhaustive.
Chorus Micro-kernel (written in C++)
Choices (research OS, University of Illinois, written in C++, supports SVR4)
GEOS (GeoWorks', written in Object Assembler, OO superset of 8086)
Mach (CMU, supports BSD 4.3, really message-based)
NachOS (written in C++, OS teaching/learning OS)
Ouverture Project (ESPRIT funded OMG IDL defines inter-module interfaces)
SOS
Spring (Sun, written in C++)
PenPoint OS (Go, written in C++)
From: whitney@oberon.Meakins.McGill.CA ()
Insight ETHOS: On Object-Orientation in Operating Systems
ISBN 3 72811948 2
This thesis covers the design of an extensible object-oriented
operating systems. The language used was Oberon-2. It includes
a generalization of the Rider/Carrier principle, Object Directories
as well as basic OS issues such as memory, file, tasking management.
It covers extensible objected-oriented programming from hardware up.
It reviews other designs such as Clouds and Choices which where written
It reviews other designs such as Clouds and Choices which where written
on C++. [[ The lack of type-tests in C++ was a problem in other designs.]]
ETHOS was implemented as an operating system for the Ceres computers
at the ETH.
3.7) What Are The Current Object-Oriented Methodologies?
---------------------------------------------------------
Here is a list of OOSE Methodologies:
Berard [Berard 93]
BON [Nerson 92]
Booch [Booch 94]
Coad/Yourdon [Coad 91]
Colbert [Colbert 89]
de Champeaux [de Champeaux 93]
Embley [Embley 92]
EVB [Jurik 92]
FUSION [Coleman 94]
HOOD [HOOD 89]
IBM [IBM 90,91]
Jacobson [Jacobson 92]
Martin/Odell [Martin 92]
Reenskaug (OOram, was OORASS) [Reenskaug 91]
ROOM [APPENDIX D, ObjecTime CASE Toolset]
Rumbaugh et al. [Rumbaugh 91]
Shlaer and Mellor [Shlaer 88 and 92]
Wasserman [Wasserman 90]
Winter Partners (OSMOSYS) [Winter Partners]
Wirfs-Brock et al. [Wirfs-Brock 90]
Further Ideas And Techniques:
Meyer [Meyer 88]
Stroustrup [Stroustrup 91]
See APPENDIX D for CASE systems supporting these methodologies (several from
the originators themselves).
See also section 1.21 for a discussion on OOA/OOD and etc.
Summaries and comparisons will be provided in future FAQs. Suggestions for
inclusion of other major or new methodologies should be sent to the FAQ author.
Here are some comparison studies posted to the net:
Arnold, P., Bodoff, S., Coleman, D., Gilchrist, H., Hayes, F., An Evolution of
Five Object Oriented Development Methods, Research report, HP Laboratories,
June 1991
de Champeaux, Dennis and Faure, Penelope. A comparative study of object-
oriented analysis methods. Journal of Object Oriented Programming (JOOP), pp
21-32. Vol.5, No. 1, 3/4-92
Fichman R.G. & Kemerer C.F. OO and Conventional Analysis and Design
Methodologies. Computer, Oct 1992, Vol 25, No. 10, p 22-40
Fichman, Robert and Kemerer, Chris. Object-Oriented and Conventional Analysis
and Design Methods - Comparison and Critique. IEEE-Comp, Oct, 1992, pp 22-39.
OOA, OOD, conventional analysis, conventional design, DeMarco SA, Yourdon SA,
Bailin OO requirements specification, Coad-Yourdon OOA, Shlaer-Mellor OOA,
Yourdon-Constantine SD, Martin information engineering design, Wasserman OOSD,
Booch OOD, Wirfs-Brock responsibility-driven design.
Hong, S., van den Goor, G., and Brinkkemper, S. A Comparison of Object-
oriented Analysis and Design Methods. Working paper, Computer Information
Systems Department, Georgia State University, Atlanta USA, 1992, 12 pages. To
appear in the Proceedings of the 26th Hawaiian international conference on
System Sciences, IEEE Computer Science Press.
Hong, S., van den Goor, G., Brinkkemper, S. A Formal Approach to the Comparison
of Object-Oriented Analysis and Design Methodologies, Hawaii International
Conference on System Sciences (HICSS) (IEEE Computer Society Press, Hawaii)
1993, Vol. IV, pp. 689-698. Summary of [van den Goor et.al., 1992] below.
Order procedure:
Available from the authors at cisssh@gsusgi2.gsu.edu or sjbr@cs.utwente.nl.
The authors, regretfully, cannot supply ftp, postscript, TEX, or
whatsoever.
Monarchi, David and Puhr, Gretchen I. A Research Typology for Object-Oriented
Analysis and Design. CACM/September 1992/Vol.35, No.9, pp35.
[Wilkie 93] summarizes, compares, and provides examples of Booch, Wirfs-Brock,
Hood, Coad and Yourdon, Winter Partners, Shlaer and Mellor, Jacobson,
Wasserman et al, Rumbaugh, Reenskaug et al, and Colbert.
Wirfs-Brock, R.J. and Johnson, R.E., "Surveying Current Research in Object-
Oriented Design," The Communications of ACM, (33, 9) Sept. 1990, pp. 104-1124.
UNICOM. Approaches to Object-Oriented Analysis and Design.
tel: l 44 895 256 484. Ask the TOC and have a look at it.
Also commercially available:
An Evaluation of Object-Oriented Analysis and Design Methodologies (9)
J. Cribbs, C Roe, S. Moon
SIGS Books
(212) 274-0640
$149.
Object-Oriented Methodology Comparison Study (10 methodologies)
Berard, Booch, Coad/Yourdon, Colbert, Embley, IBM, Martin/Odell, Rumbaugh,
Shlaer/Mellor, Wirfs-Brock. Also contains refs to several previous studies.
Berard Software Engineering
101 Lakeforest Blvd., Suite 360, Gaithersburg, MD 20877
Contact Person: Jim Youlio
Phone: 301-417-9884
Fax: 301-417-0021
email: info@bse.com
[van den Goor et.al., 1992] G. van den Goor, S. Hong and S. Brinkkemper,
A Comparison of Six Object-oriented Analysis and Design Methods. Report
Center of Telematics and Information Technology, University of Twente,
the Netherlands, and Computer Information Systems Department, Georgia
State University, Atlanta, USA, 1992, 163 pages, US$ 70.
This report gives an in-depth analysis of six generally accepted
O-O methods, that are available in textbooks. The background, steps,
concepts, notations, and specification techniques of the methods
are extensively compared.
The six methods are:
- Object Oriented Analysis & Object Oriented Design (OOA/OOD) of Coad &
Yourdon (1991)
- Designing Object Oriented Software (DOOS) of Wirfs-Brock et.al. (1990)
- Object Modelling Technique (OMT) of Rumbaugh et.al. (1991)
- Object Oriented Systems Analysis (OOSA) of Shlaer & Mellor (1988)
- Object Oriented Design with Applications (OODA) of Booch (1991)
- Object Oriented Analysis and Design (OOAD) of Martin & Odell (1992).
The comparison is performed by meta-modelling, resulting into detailed
information on the concepts of the methods (in EER notation) and on the
steps of the procedure of the methods (in Task Diagrams). Extensive
comparison tables of steps, concepts, techniques are included. Mappings of
the methodical concepts to the constructs of programming languages (C++,
Objective-C, Smalltalk-80, Object Pascal en CLOS) are given. A small
test case illustrates the application of the methods.
Order procedure:
Those who want to order the complete report (163 pp.) can order one by
specifying their postal address in an e-mail (sjbr@cs.utwente.nl) or fax
(+31.53.33.9605) attn. Sjaak Brinkkemper. The report will be send within
two weeks with an invoice for US$ 70. (seventy dollar; including shipping,
excl VAT).
3.8) What Is the OMG/OMA/ORB/CORBA?
------------------------------------
Contents:
(3.8.1) Contact Information
(3.8.2) OMG Summary
(3.8.3) Mail Server Access
(3.8.4) OMG Publications
- First Class (Bi-Monthly Newsletter)
- Object Management Architecture Guide (OMA)
- The Common Object Request Broker: Arch. and Spec. (Corba)
- Pricing
(3.8.5) Implementations (Brief)
(3.8.6) Implementation Descriptions
(3.8.7) Books, Articles, And Literature
3.8.1 Contact Information
__________________________
Contact Person: Richard Soley (technical director) soley@omg.com
FTP Sites:
omg.org:pub/*
omg.org:pub/NEC_DII/93-1-2.tar... *CORBA (DII) (corba.ps.Z)
omg.org:pub/OMG_IDL_CFE_1.2/bin* idl.SunOS4.x, idl.Solaris2.x
claude.ifi.unizh.ch:under pub/standards/spec CORBA Spec
Headquarters: Marketing Office:
492 Old Connecticut Path 3823 Birchwood Drive
Framingham, MA 01701 Boulder, CO 80304
Tel: 508-820-4300 Tel: 303-444-8129
Fax: 508-820-4303 Fax: 303-444-8172
3.8.2 OMG Summary
__________________
Go Back Up
Go To Next