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.
The nfoCentrale Blog Conclave
nfoCentrale Associated Sites
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:
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:
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.
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.)
|You are navigating Orcmid's Lair.|