Re: The IDS, the EDS and the DBMS

"erk" <eric.kaun_at_pnc.com> wrote in message news:f556e3abffeb4a81492c665557f40d2c_at_localhost.talkaboutdatabases.com...
> I'm a latecomer to this thread (and most others at this point), but will
> jump in anyway.

Welcome!

A lot of what you say in the following is over my head, but I asked for that when I started the thread.

> bad modularization
> can be worse than no modularization, and the same holds for encapsulation.

Agreed!

Also, bad relational design can be worse than no relational design. Bad object modeling can be worse than no object modeling. Bad database management can be worse than no database management.

Whenever there is a lever on additional power, the learner has to learn to do the right things, and also how to do things right.

>
> 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.

What is ADT?

I see static public methods as a way of carrying over all the stuff I think I gained from subprogram libraries in a structured programming environment. In other words, one of the ways I can cope with new things is by relating the new thing to things I already know. One of the things I want in an OO environment is a way of carrying over those strengths that don't require the additional power that OO makes available. "Static public methods" sounds like that to me.

When I first learned solid geometry, they didn't say "forget everything you learned in plane geometry; it's all wrong!"

When I first learned Einsteinian mechanics, they didn't say, "forget everything you learned in classical mechanics; it's all wrong!"

When I was first exposed to object oriented programming, they said, "forget everything you have learned in 25 years of professional programming; it's all wrong!" I decided to wait until they had calmed down a little. They did.

>
> 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.

I worked with a Lisp type language years and years ago. When I read the Rumbaugh book (which is, by now, "Stone Age" to the twentysomethings of IT) they emphasized three largely orthogonal models: the object model, the dynamic model, and the functional model. The functional model reminded me a great deal of my experience with Lisp.

> 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.

There's that number 3 again. It keeps cropping up. For me, there are three things you can do with data:
You can process data. You can store data. And you can transmit data. Almost anything that adds value to data is a blend of all three of these.

>
> > 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.
>
> Type implementation; I think Date had it right in suggesting that type
> implementations could be done in a variety of languages, and even that
> those languages might be different than those used in the rest of the
> app...
>

I guess I don't really understand the difference between type implementation and integrity enforcement.

A type definition defines the elements, their representations, and the operations defined over them. Isn't this a form of integrity? Or am I missing something? Received on Wed Sep 08 2004 - 15:25:44 CEST