hume@buckwheat.sps.mot.com (Chris Hume) (10/06/89)
The following is yet another attempt to provide an answer to the question:
"What is Object Oriented Programming, anyway?" Answers to questions of
this profundity will, of course, be as diverse as the readers of these
newsgroups. In order that the concept not be so "fuzzy" as to be useless,
however, some attempt to extract a common vision will be helpful.
In many respects we are talking about an "attitude" or a "point of view".
Some may prefer to concentrate on specific "features", but we also need
to develop a sense of what the motivations for these features are. This
would seem to be the point of investigating Object Oriented Philosophy.
Perhaps the most fundamental contribution of Object Oriented Philosophy
is the continued improvement of Tools and Practices allowing Implementors
to keep Functional Requirements clearly in view while protecting Users
as much as possible from Implementation Detail.
This is accomplished through a series of abstractions the central aim
of which are to make the Use of any Class of Objects more "Intuitive".
Beyond the basic concern that Intuitiveness be enhanced, Object Oriented
Philosophy aims to promote a number of desireable Interface Characteristics
which promote some aspect of "Interactivity".
One of the more widely accepted "features" of an Object Oriented Computation
Model is that Predicates (or Function Specifiers) are strongly encouraged
to adopt consistent semantic interpretation across all Object Classes.
Another central feature is that an Object Class encapsulates (maintains
internally) the distinctive state bearing potential (or the permissible
configurations) necessary to give the Class its Functional Character.
The User (or Client) of an Interface to any Instance of an Object
(a specific member of some Object Class) should be provided with various
means of diagnosing (or viewing) an Object's "state" to whatever degree
will be sufficient to verify the Functional Behaviour a Class supports.
At a minimum the User must be provided with the means to Create, Destroy,
and detect the presence of Instances of an Object Class.
These "diagnostics" are expressed in terms of Diagnostic Parameters,
which are drawn from fairly primitive Object Classes so as to limit
the amount of further Interface invocation required before their
value can be "viewed".
Strings and Numbers are useful Diagnostic Parameters because when
printed they can convey immediately the value of whichever metrics
may have been established to characterize the Object's state.
Where a diagnostic returns an Object associated with a Functional Dependency
(such as a File's Name) this Object should be of a Class directly associated
with that Functional Behaviour so the User will interact with this constituent
in a manner compatible with the apparent Conceptual Dependency. This has
the benefit of keeping the Parametric and Functional Dependencies more or
less "isomorphic". Parametric Dependencies may or may not introduce strict
Class Dependencies (one form of Implementational Dependency), depending on
the level of Class (or Type) Abstraction permitted by a given Implementation
Language.
One of the outstanding concerns for Software Design is the question
of the extent to which Functional Dependency must be "contractually"
specified. This issue presses because Functional Dependency codifies
the degree to which Users and Implementors will agree upon and support
the same Conceptual Model.
Functional (or "definitional") Dependency is essentially a dictionary
within which the Functional Behaviour of Complex Objects is defined
in terms of the Functional Behaviour of more Primitive Objects.
This language is used to formally specify requirements that have
been identified as those necessary and sufficient to provide an
Object Class with behaviour compatible with an anticipated Conceptual
(or Interface Usage) Model.
For example, one might define the Functional Behaviour of a primitive
Object Class named "Name". Then in the process of defining the Functional
Behaviour of a complex Object Class named "File", one might refer to the
behaviour previously specified for "Name" as having been assumed as one
aspect of the behaviour now being defined for "File": the File's Name.
(One possible state for a File is that it may not yet been assigned its
Name.)
In the conventional (although somewhat disorienting) terminology, the
"Name" class would then be identified as a (direct) super-class of "File",
and "File" would be identified as a (direct) sub-class of "Name". Class
Dependencies are therefore directed (and are also best kept acyclic,
or non-recursive.)
Given a hierarchy of Class Dependency, it is also possible to specialize
(or qualify) the "default" behaviour of any (constituent) Super-Class
within the context of a Sub-Class in which it appears. This is another
distinctive "feature" of Object Oriented Philosophy, which contributes
a powerful and robust mechanism whereby re-use of previously defined
functions is promoted. In effect, this feature provides Implementors
the means by which they can provide function they Use to their Users.
Thus, it helps support isomorphism between Implementational and
Conceptual Dependencies.
NOTE: There is some ambiguity in the term Implementational Dependency.
The term is intended to refer to internal dependencies about which
Users are assumed to have no knowledge, but Implementational
Dependencies are placed in direct support of the Functional,
Parametric, and Conceptual Dependencies that have been advertised
to Users. Implementational considerations also generate Functional
Requirements, which further Functional Dependencies will be
introduced to satisfy. The number of additional (or pragmatic)
Functional Dependencies will be reduced to the extent that
Implementational Dependency coincides with Conceptual Dependency.
We may also consider "Modal Specialization". Where the behaviour of a
class might be divided into related "cases" which are selected on the
basis of the value of certain state variables to support various "Modes"
or "Views" of a certain set of Instances.
Another important tool (recognized long before the advent of Object
Oriented thinking) allowing the various Implementational Assumptions
to be expressed, is the notion of "assertions" including: "preconditions",
and "postconditions". These are useful if only provided as Human Readable
Documentation, but enforcement mechanisms (such as automatic signal
generation) can enhance their utility to the maintenance of Implementation
Correctness.
A Conceptual Model of how the Instances of a Class behave under the
stimulus of its "state modifying" Interfaces must somehow be internalized
by the User. This is usually done in the form of Documentation appealing
to more Primitive Concepts the User is assumed to have already internalized.
Ultimately, the most Primitive Concepts must appeal to "Common Sense".
Actually, it is important that Interfaces be kept as "Intuitive" as
possible at EVERY level. This relates to the reality that any significant
piece of software will be both Used and Maintained by a diverse community,
and not by one Implementor. (Even in the case where Implementors maintain
exclusive interest in a Design, Humans have to deal with the problem of
our Limited Memory capacity which Intuition can substantially alleviate.)
The User's internal model includes visualization of: Functional and
Parametric Dependency, as well as the Intrinsic Behaviour (or state
bearing potential) of each Class. The means to both "exercise" and
"reinforce" this Conceptual Model must be provided.
Some of the characteristics of Object Oriented Philosophy that have
been briefly touched on here are summarized below:
1. Semantically Consistent Interfaces (or Predicates)
2. Encapsulation of the Conceptual (or Behavioural) Model
in an Interactively Accessible form
3. Controlled Isomorphism between the distinct Conceptual,
Functional, Parametric and Implementational Dependencies
with its consequent benefit to overall Intuitiveness
4. Behavioural Specialization whether by Functional or
"Modal" Context, allowing Behavioural Re-Utilization,
which in turn lends support to Controlled Isomorphism
5. Explicit Assertion of the Implementational Assumptions
to help maintain Correctness
I have these points in the framework of Dependency Management,
in an attempt to emphasize how intimately connected Object
Oriented Philosophy is to the problems of (Software) Engineering.
The philosophy embraces a number of ideas which have gradually
emerged as contributing positively to Software Engineering.
Chris
--
Phone: (602) 994-6835 EMail: hume@sps.mot.com
"A society that is relatively free and open at home may be brutal
and murderous abroad." - Noam Chomsky, On Power and Ideologykcr@netxdev.DHL.COM (Ken Ritchie) (10/25/89)
Read Jim Waldo's article, "A New Generation", in UNIX REVIEW (vol 6, nr 8). You see any technotrivia there, but Waldo makes a great statement for the CONCEPTUAL BASIS, and explains WHY the OO perspective IS DIFFERENT (from SP, etc.)... he appeals to Thomas Kuhn's classic, THE STRUCTURE OF SCIENTIFIC REVOLUTION (1970)... Waldo states: "the intangible something that distinguishes the OO practice is that it, unlike conventional programming, is a form of classic metaphysics." What he means, I think, is that the model is based on "modelling" aspects of the world in some abstract way which happens to map nicely onto reality. It amounts to a paradigm shift. I think it's worthwhile to be aware of the source of "leverage" one gets from a tool, language or paradigm -- and also to be conscious of the limitations we incur (Dijkstra/Sapir-Whorf, in the arena of linguistics: the tools/etc even limit our conceptual ability). I hope this helps you... it was nice reading, anyway. [Now, back to coding...] _______________________________________________________________________________ Ken Ritchie (aka KCR) Usenet: ...!uunet!netxcom!netxdev!kcr NetExpress Communications, Inc. 1953 Gallows Rd, Suite 300 FAX: USA (703) 749-2375 Vienna, Virginia (USA) 22182 Voice: USA (703) 749-2268 "Imagination is more important than knowledge." -- Albert Einstein Disclaimer: We have over 100 people here, and each one has an opinion or two... _______________________________________________________________________________