Re: Object-oriented thinking in SQL context?

On Jun 17, 11:55 am, Marshall <marshall.spi..._at_gmail.com> wrote:
> On Jun 17, 4:45 am, "Nilone" <nil..._at_mega.co.za> wrote:
>
> > "Bob Badour" <bbad..._at_pei.sympatico.ca> wrote in message
>
> > >> Think 'class' ~ 'relation' (table)
>
> > > But that would not only be a blunder but a great blunder.
>
> > I'd like to clarify this for anyone coming from the OO side. If you map
> > class to relation, you're breaking the OO rule of encapsulation and reducing
> > the class to a simple aggregate type (struct). Presumably, you chose an
> > encapsulated, polymorphic abstraction device for a reason, or did you do so
> > just because you (or somebody at your company) read Lhotka's book? Classes
> > map to domains (types) in the relation model, but be aware that subclassing
> > is NOT subtyping.
>
> Speaking just for myself, when I am programming in an OO language,
> I map classes to whatever I feel like. OO really only provides the
> one unit of abstraction, the class. If the only tool you have is a
> class, everything looks like an object. Or something.
>
> In other words, when I want an abstraction for something in
> Java, I make it a class, because that's about the only choice.

Maybe this is a vocabulary mismatch problem; but it seems you're leaving out an important unit of abstraction: functions. Or what and I misunderstanding? (Note here I have in mind C++, Lisp, and other OO languages that support free functions.)

KHD Received on Sun Jun 21 2009 - 06:00:06 CEST