The Quarks of Object-Oriented Development
Deborah J. Armstrong provides a valuable conceptual classification of features for object-oriented (OO) development (2006). Armstrong reviewed the literature for characterizations of essential OO qualities. She synthesized a taxonomy based on concepts emphasized in a majority of 88 sources. I recommend the general adoption of the eight fundamental concepts (quarks) and the distinction of structure and behavior that Armstrong recommends.
{tags: object-oriented development OO concepts Deborah Armstrong What Computers Know conceptual integrity taxonomies orcmid}
The Recommended OO Taxonomy
Armstrong is looking for more than identification of fundamental concepts for which there is good agreement. The proposed taxonomy is organized to show how “these concepts fit together in a coherent scheme.”
Armstrong recognizes two categories (called constructs): structure and behavior. The structural concepts are focused on the class/object relationship in OO approaches. Behavioral concepts relate to object actions within an OO system. In repeating the article’s Table 3, I have added the italicized summaries that are provided as part of the analysis in the text. If there is anything different in the 2003 version originally submitted for publication, I have added those definitions too. Definitions that are identical between the text, the table, or the two versions of the paper are not repeated.
| Construct | Concept | Definition |
|---|
| Structure | Abstraction: | the act of creating classes to simplify aspects of reality using distinctions inherent to the problem.
Creating classes to simplify aspects of reality using distinctions inherent to the problem. 2003: the act of representing reality in a simplified form by removing certain distinctions so that we can see the commonalities.
Representing reality in a simplified form by removing certain distinctions so that we can see the commonalities. |
| Class: | a description of the organization and actions shared by one or more similar objects. 2003: a generalized description of one or more similar objects that share a common structure and common behavior.
A generalized description of similar objects that share a common structure and behavior. |
| Encapsulation: | a technique for designing classes and objects that restricts access to the data and behavior by defining a limited set of messages that an object of that class can receive.
Designing classes and objects to restrict access to the data and behavior by defining a limited set of messages that an object can receive. 2003: a technique for designing objects in which attributes and methods are defined within a single object and separated from everything else, thus protecting the internal representation of the object.
Data and behavior are defined within an object and separated from everything else, protecting the internal representation of the object. |
| Inheritance: | a mechanism that allows the data and behavior of one class to be included in or used as the basis for another class.
The data and behavior of one class is included in or used as the basis for another class. 2003: a relationship between classes that allows for the data and behavior of one class to be based on another existing class.
Allows the attributes and methods of one class to be based on another existing class. |
| Object: | an individual, identifiable item, either real or abstract, which contains data about itself and the descriptions of its manipulations of the data. 2003: an individual, identifiable item, either real or abstract, which contains information about itself and the descriptions of its manipulations. |
| Behavior | Message Passing: | the process by which an object sends data to another object or asks the other object to invoke a method.
An object sends data to another object or asks another object to invoke a method. 2003: the process by which an object sends information to another object or asks the other object to invoke a method.
The process by which an object sends information or invokes a method. |
| Method: | a way to access, set, or manipulate an object's information. 2003: Accessing, setting or manipulating an object's information. |
| Polymorphism: | the ability of different classes to respond to the same message and each implement the message appropriately.
Different classes may respond to the same message and each implement it appropriately. 2003: the ability of different objects to respond to the same message and each implement the method appropriately.
Different objects can respond to the same message and implement it appropriately. |
Reflections on Taxonomy
I notice three lessons here:
- Armstrong compares her taxonomy with two others. It appears that it is difficult to translate faithfully between any two of the three. This is an interesting challenge for those who think differences in ontological schemes can be reconciled mechanically.
- The definitions still aren’t sharp. I hadn’t intended to compare the two versions this way, but there is a certain level of equivocation and, I think, weak definitions that are going to require further discussion to shake out. In the table, Object and Method have changed the least between text, table, submission and publication yet I would still quarrel over them (but not here).
- The basic taxonomy of eight fundamental concepts in two categories is a keeper. Although I would quibble over how to sharpen the definitions, I see no reason to change the selection of concepts.
Reflections on Object-Oriented Technology
I’m also intrigued by the first level of concepts that did not rise above 50% popularity among the materials that were analyzed.
I think we should pay special attention to the critically-important manifestation category, including execution architecture, deployment, and instantiation concepts. I’d like to see that singled out for additional treatment.
I also think this would help us shake out the already-proposed categories. For example, the notion that it is the classes that respond to messages (see the Polymorphism entry) smacks of a serious implementation assumption. There are other ways that providing a category for key implementation features would help us expunge residual implementation notions from the top eight fundamental concepts.
The influence of the particular OO technology on how OO development is approached cannot be underestimated overestimated. In addition, it may be valuable to focus on how the technology has nothing whatsoever to do with “aspects of reality,” positioning us to take a sharper look at just where reality and OO technology in computer software have any connection whatsoever.
- Armstrong, Deborah J. (2006)
- The Quarks of Object-Oriented Development. Comm. ACM 49, 2 (February 2006), pp. 123-128.
The original 2003-03-01 report ITRI-WP034-0303 is available as a free PDF download. The results are essentially-identical between the original and the updated analysis, although there are intriguing nuances where the two differ.
- see also:
- Orcmid's Lair 2006-02-03: What Computers Know
[update 2006-02-19-15:42 Well, I got an idiom wrong (see the last paragraph) and took the opportunity to tie in “What Computers Know.”]
posted by orcmid
at 2/19/2006 03:14:11 PM,
rating
data by NewsGator
Online
