Re: The IDS, the EDS and the DBMS
Date: Tue, 07 Sep 2004 12:41:05 -0400
Message-ID: <f556e3abffeb4a81492c665557f40d2c_at_localhost.talkaboutdatabases.com>
I'm a latecomer to this thread (and most others at this point), but will jump in anyway.
Marshall Spight writes:
"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> Heh. I've never understood OO as anything else but: one way of
> accomplishing modularization. By viewing a certain compound
> of (passive) data and (active) behaviou?r (an 'object' or 'actor')
> as a collaborating, responsible unit, this shared (by the design
> team) metaphore helps organizing the code in modules...
I don't disagree, but that's more truism than truth, and assumes modularization and encapsulation (not the same thing) are self-evident goals. In any of themselves, they're just assertions; bad modularization can be worse than no modularization, and the same holds for encapsulation. I'd agree with Marshall that perhaps we just don't have it right yet, or at least no consistent principles.
O-O itself can be used in the sense of ADTs (the data-behavior coupling), but also, in most modern O-O languages, it is assumed to be an organizing principle for all development, not just types per se. That's where things get dicey. Any Java app I've ever seen has static public methods, often in a class with nothing but static public methods. What exactly is the value of O-O in that? In that case, the package and class name form a useful namespace; none of the other features of O-O do anything but detract from the structure.
Consider a very different paradigm: functional languages like Lisp. The power of its reuse is extraordinary, and yet encapsulation and objects are simply ignored (to a large degree). You can achieve much leverage and abstraction with no coupling of function and structure; in fact, the power comes from functions applied to arbitrary structures.
Witness design patterns; how many of them simply go away in the presence of a properly-typed language like Haskell or ML? Don't patterns like Visitor and Strategy and Command cry out for functions to be treated as first-class language citizens? How many patterns are devoted to factory concepts (including Flyweight), belying the value of Java and C++-style "new" instantiation?
O-O has much to learn (mostly its place), and I think the "ultimate language" will use Third-Manifesto O-O concepts for types, relations for data manipulation, and first-class functions for... well, I'm not sure, or I'd have written the damned thing by now. But I think those 3 concepts are all critical to development.
> Consider what one uses encapsulation for:
> to enforce certain invariants in data structures.
> Isn't declarative integrity constraints a uniformly
> superior mechanism for doing that?
Yes, exactly.
> If there is more to encapsulation
> than enforcing integrity, I'm not aware of it.
> > What is needed, then, is not a "mapping" from one to
> > the other, but rather a *unification.*
- Eric