hume@buckwheat.sps.mot.com (Chris Hume) (10/11/89)
[My earlier "What is Object Oriented Programming, anyway?" evoked two private responses, the point of one being simply that the posting became illegible due to an impression that capitalization is a form of "shouting". Perhaps this feeling is shared by others, so I have attempted to "attenuate" the level of capitalization in this posting. In addition to its conventional application, I often use capitalization as a "topicalizing" device: to underscore the objects I am attempting to relate. Hopefully, it won't be much longer before standard (and convenient) means of incorporating various fonts/faces into these postings emerge. Then we can annoy each other with ever more eccentric preferences. The other respondent lost the thread of discussion in the following paragraph: >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.] In order to clarify the explosion of various "sources of dependency" set off in the prior posting, the following division into three major categories may prove helpful: Intuitive Dependencies ---------------------- Conceptual - Essential Character explained via appeal to Intuition/Education Parametric - Inherited due to (the "natural") Predicate Argument Structure === The Natural Language/Computational Mechanism Translation Boundary === Visible Dependencies -------------------- Functional - "Contractually" proscribed (as sufficient and/or necessary) Behavioural - Validation of Essential Character as observed via Interaction === The Usage/Implementation (or Client/Server) Protection Boundary === Hidden Dependencies ------------------- Class Heritage - Essential Character "expedited" via Modular Assembly Class Usage - Assembly integrated via State Specialization (or "glue") The source of Intuitive Dependencies is that, as Humans, we all share common requirements (whether as Clients or Servers) in the process of requesting (and granting) services. These requirements are due in large part to our common genetic heritage, but owe also in part to shared environmental experiences (or Education). Visible Dependencies are motivated by a select set of individuals (or individual behaviours) where more esoteric considerations such as logical consistency and optimality are brought into sharp focus. We hire architects to make sure that our buildings won't fall down, and that the plumbing will be adequate, etc. The Hidden Dependencies are the domain of a contractor, a member of the Guild of Implementors. This person is expected realize the requirements set forth by the architect, in a reasonably sound and "contractually compliant" manner. The correct realization of "Functional Requirements" has a substantial creative, authoring component. It is very similar to the process of developing a mathematical proof. In the real world, Implementors must also bear in mind "unspoken" and "developing" requirements. In software of course, the implementor of "high level" services is in turn a user of "low level" services. Separating these distinct roles is identified above as "The Usage/Implementation (or Client/Server) Protection Boundary". This is the fence that protects the activity of different groups of individuals, who have taken up "modularly compartmentalized" responsibilities, from mutual interference. The ability to "program" is actually to some degree inherent in anyone (or thing) who makes requests of anyone else. Where Humans are involved, however, we must be careful to acknowledge the very real existence of strong constraints imposed on the process of communication. This is identified above as "The Natural Language/ Computational Mechanism Translation Boundary". To represent the thrust of my earlier message: Object Oriented Programming helps satisfy the major requirements imposed by the existence of these boundaries, while also allowing their various dependency hierarchies to be kept in some degree of correspondence across these boundaries (at every level.) Now, an attempt to clarify the earlier point concerning maintenance of isomorphism between Functional and Conceptual Dependency follows: >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.** Interaction is expressed in terms of the Predicate Argument Structure of a conventional set of predicates (or messages.) In terms of natural language: the direct object(s) are manifest as those objects toward which imperatives are primarily directed, and the indirect object(s) as supplementary arguments normally associated with a "generic" interface invoked by the predicate. This argument (or "parametric") structure has its imprint in the form of additional dependency structure for any class of object choosing to support a particular predicate. (Depending on the Implementation Language, these dependencies may or may not be "abstract" with respect to parameter classes requirements.) Where appropriate Functional Dependencies have been set forth, presumably for their relevance to an anticipated Conceptual Model, interaction should produce objects of a class associated with these Functional Dependencies. This is true even in the case of diagnostics, where the primary purpose is to view (or probe) the object. Any parametric output will also lend itself to viewing and probing, but the methods defined for accomplishing this should not substantially mask the constituent's identity (where its presence is motivated by functional requirements.) This point is subtle, but sensitive because it constrains implementation to a degree. Chris -- Phone: (602) 994-6835 EMail: hume@sps.mot.com