Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: 2 Jun 2006 10:14:53 -0700
Bob Badour wrote:
> I understand the concepts of abstraction and information hiding.
> However, I have yet to see anyone put forward a decent argument for
> creating a layer in which to hide the higher-level abstractions from the
> lower-level abstractions. Usually, information hiding works in the other
> direction by hiding the lower-level details to keep them from getting in
> the way of human comprehension.
> Relations, the relational algebra and the relational calculus are much
> higher-level abstractions than any in OO.
Although the higher-level relations make use of types/domains (for which O-O can be used), there's little doubt which is higher level.
You can also see other examples of higher-level language features in the recent spastic attempts to introduce decent dynamic functional features into O-O, in the form of aspects. It won't be the last time O-O proponents try to pull mutant versions of functional features into the "paradigm."
> Explain how it makes sense to avoid
> using predicate logic for expressing logic or how it makes sense to
> avoid using a data management system for managing data.
It's of approximately the same category as the tendency for Java systems to have endless numbers of static methods and "classes" with nothing but static method, because Java lacks not only functions as first-order entities, but long-established and extremely useful features as multimethods and pattern-based function definitions.
> Predicate logic is well-defined. Set theory is well-defined. The
> relational algebra and calculus are well-defined. These are all
> formalisms that are well-defined both syntactically and semantically.
> They are the current culmination of a couple millenia of advances in
> mathematics and logic.
What theories there are in O-O (e.g. the writings of Luca Cardelli) are, by and large, ignored by O-O languages and "frameworks." It's sad that languages like Lisp, which have not only "done objects" well but provided higher-level protocols (the Meta-Object Protocol or MOP) for manipulating and defining object systems, have been neglected in favor of languages which confine developers to awkward, emasculated, theory-free "objects."
> OO offers nowhere near the functionality provided by either the
> relational algebra or the relational calculus in any manner useful or
> otherwise. Neither is it anywhere near as elegant as the RM nor does it
> provide anywhere near the same level of physical or logical independence.
Several buzzword-driven cases which support this thesis:
- "Service-oriented architecture": a design "pattern", typically being wrapped around O-O languages, which attempts to circumvent the usual object instantiation protocols in order to "flexibly" configure instances responding to a given request. This overthrows 3 common "features" of O-O: the services aren't objects in any normal sense, the identity of the service "objects" is explicitly hidden, and instantiation is explicitly hidden.
- Continuations and closure in web apps and in "objecty" languages
like Python and Ruby and Perl. These are both functional in nature;
thus the OOgy languages are miraculously rediscovering the objecty
benefits of old, functional concepts.