Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

Recent Items
 
The Quarks of Object-Oriented Development
 
Performing in Teams: Where's the Praxis?
 
Windows Home Server Edition
 
The Ultimate Confirmable Incoherence Experience
 
To Express or Not To Express: Choosing a C/C++ Compiler
 
Agile Builds: Making a Bad Idea Efficient?
 
Patterns: Starting in the Meta-Middle
 
Without Context, Every Open-Format Standard Is the Best
 
Second-Guessing Microsoft on ECMA: Shape-Shifting the ODF
 
Lining Up Open Formats for Office Documents

Archives
2004-06-13
2004-06-20
2004-06-27
2004-08-29
2004-09-05
2004-09-12
2004-09-19
2004-10-10
2004-10-24
2004-11-07
2004-11-28
2004-12-05
2004-12-12
2004-12-26
2005-01-30
2005-02-06
2005-03-06
2005-03-13
2005-03-20
2005-04-03
2005-04-10
2005-04-17
2005-04-24
2005-05-01
2005-05-08
2005-05-15
2005-05-29
2005-06-05
2005-06-12
2005-06-19
2005-06-26
2005-07-10
2005-07-17
2005-07-31
2005-08-28
2005-10-09
2005-10-16
2005-10-23
2005-11-13
2005-11-27
2005-12-04
2005-12-18
2006-01-08
2006-02-05
2006-02-12
2006-02-19
2006-03-05
2006-03-12

Blinking at Quarks: Is It an Object that I See Before Me

[I am using this article for serious purpose and also as part of an investigation of the confirmable experience (or lack thereof) of Technorati Tags.  The tags in the earlier article have not been indexed on Technorati and it is unclear why.  This provides a demonstration of the many mysteries that prevent trouble-shooting and verification of a web service where there isn’t anyone at the other end, the intervention of intermediaries is an unknown quantity, and it is not possible for an user to know what happened, only what the consequences are.  All of that will be the subject of other articles.  The mystery is whether the taggings in this article will make it into the Technorati index.]

[update 2006–03–17: I see a place where I used an incorrect name where Deborah Armstrong was intended and want it repaired.  That will also incorporate this page under my visitor map.  I am tightening up a few passages as long as I’m here.]

{tags: object-oriented development OO concepts Deborah Armstrong What Computers Know conceptual integrity taxonomies orcmid}

Professor von Clueless in the Blunder Dome: The Quarks of Object-Oriented Development.  I was discussing Deborah Armstrong’s analysis of fundamental OO concepts in last week’s buddy call with colleague Bill Anderson.  It was easy for us to start challenging the lack of sharpness in the definitions.  I think it is worthwhile to point out a couple of difficulties and also point out how a common practice of software development trips us up.

Descriptive Versus Prescriptive Taxonomies

Before starting, I must emphasize that Armstrong’s classification is meant to be descriptive.  Works of others containing descriptive (or prescriptive) characterizations of object-oriented development were analyzed and summary descriptions of the top eight concepts were then synthesized.  On reflection, it might have been useful to use a lexicographic approach that tolerated different definitions that seemed to cluster out.  That wasn’t done.

To the extent that the result lacks sharpness and may even be confusing, that is evidence for the state of the shared understanding of experts on the matter.

In offering alternatives, although they strike the author as the complete truth of the matter, please ignore the presumption of validity.  These offerings should merely be taken as demonstrative of where clarity is lacking and incoherence can be found.

Reality Versus Computational Representation

If we look at the tabulation for OO Abstraction, OO Class, and OO Object, it is possible to observe that the way the nomenclature is based on somewhat-familiar terms creates pitfalls when it comes to grasping what an application of those concepts is about and how that is manifest in computational artifacts and behaviors. 

In discussion with Bill I noticed that the OO-specialized categories for fundamental concepts are blurred by their suggested connection with (conceptualization of) reality as it figures in human experience.  I didn’t catch that in replicating Armstrong’s taxonomy.  I will redeem myself by capitalizing and prefixing (OO-) my mentions of OO-development concepts.  I am following my own advice with regard to data modeling.  (I won’t go so far as to speak of ooClass and ooObject, as amusing as that could be.)

Confusion with Ordinary Abstraction, Class, and Object

It is easy to confirm that OO terms are confused with the ordinary use of abstraction, class, and object.  That confusion aso clashes with the specialized usages in philosophy and (mathematical) logic, including set theory: 

• OO Abstraction, OO Class, and OO Object are identified as OO Structure concepts, and this is not exactly what one would suppose as sharp for class and object and especially abstraction generally.  There is a sense where structure might hold, but that doesn’t seem to be divorced from behavior.  I don’t want to debate the aptness of the OO Structure category.  I am simply demonstrating that this doesn't seem to refer to the structure of nature or of reality.
      
• OO Encapsulation and OO Inheritance, lumped into OO Structure with the others, are clearly observations bearing on OO technology and not nature, reality, or the nature of reality.  Notice how the definitions are all about the design of artifacts.  This is further reason for avoiding confusion of OO concepts and anything about nature and reality.

Extensional Versus Intentional Use

 In computation, it is also important to differentiate between the extensional nature of something (the “what it is” in fundamental terms, if we are so bold) and the intentional view of something (the “what it is for” or what it is an instrument or medium of).  The second is always tied to some situation or context and relies on external conditions not that inseparable from the intentional view of thing itself.  (Even what we take as extensional is possibly intentional at a lower level, but we have to start somewhere.  I touch on how we avoid falling down the rabbit hole in a more-recent article.)

For our purposes, we don’t have to worry about the philosophical subtleties here.  (The injunction to concentrate on the extensional is attributed to the philosopher Willard Van Orman Quine).  The cases that stand out in the OO-development taxonomy are much more bare-faced.

Reality Versus Problems

In the definition of OO Abstraction, we see that it is a purposive activity for “creating classes to simplify aspects of reality using distinctions inherent to the problem.”  The more I look at this, the less I understand what it could mean.  I am baffled about the prospect for simplifying aspects of reality.  I am even more concerned that “inherent to the problem” clearly depends on a particular perspective and is certainly highly-contextual.  (I also notice that OO Abstraction is characterized by its purpose and not its nature, whatever its nature might be.)  I have the following questions:

•  If an OO Abstraction is performed, where is there to be found an account of the simplifications and the problem-inherent distinctions?  Is it evident in the created classes?  Is it to be found elsewhere?
      
• If OO Classes are reusable as is often claimed, how is this reconciled with the distinctions inherent to different (perhaps-related) problems? 
      
• It would seem that OO Abstraction captures something that is essential about “reality” concerning a given situation (or “problem”) and that, to use the usual notion of abstraction, one wants to remove the inessential, incidental, or accidental. 
      
• Of course, OO technologies introduce their own often-extensive incidentals and it seems that we must now deal with those.
           
• Fred Brooks has addressed this notion of the essential and the accidental (going back to Aristotle) in his progression of articles built on The Mythical Man-Month.  Brooks is also clear that he has in mind the essence of a software entity and that this essence is abstract. 
      
• I cannot deny and certainly do not wish to refute that software entities are arrived at for some useful purpose.  However, we need to consider the different abstraction that a software entity is and what might be an abstraction of some entity recognized in the world.  How one manifests in one that which is essential of the other is tricky business.  I’m not sure what of that is meant to be distinguished under the concept of OO Abstraction.

The Subject Versus the Representation

 My final example concerns OO Object.  In the definition distilled by Deb Armstrong, it is “an individual, identifiable item … which contains data about itself and the description of its manipulations of the data.”  I must confess that “item” leaves me cold, and I wonder what had the commonplace “entity” be avoided.  My greater concern has to do with this business about data.

• If an OO Object can be said to contain data, I suggest that the data is not “about itself,” that is to say, the OO Object. 
        
• If the data is “about something” I’d say it is about (better: related to some aspect of) the abstracted entity of which the OO Object is representing something essential. 
      
• Having said that, I am willing to stretch a point and concede “description of its manipulations of the data” simply to point out that the OO Object must be what is intended for that because entities in the world (and their abstractions) can hardly be claimed to be objects having such a quality.

Pondering this, I think what’s missing is how OO Objects are organized to preserve some represented invariant in the way that data and procedures (the behaviors the OO Object is said to offer) are constrained and coordinated together.  Furthermore, these constraints, enacted in a computational entity, are what preserves some essential correspondence to something tied to our purposes for the OO Object.  It’s too mischievous to call this entity-of-our-purposes or intension “the object.”  Let’s speak of it as the OO Subject when we need to be so precise.  (I fear this opens up a torrent of refinements and my use of “subject” is already on shaky ground.)

posted by orcmid at 2/25/2006 02:50:29 PM, rating data by NewsGator Online