Re: Databases as objects

On Dec 22, 9:58 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

>

The funny thing is, I actually like OO, such as it is. Java is a better language than I otherwise would get to use.

I think it's worthwhile to identify what exactly the good ideas in OO are.
I would propose the classic troika:

  inheritance
  encapsulation
  polymorphism

Now it turns out that "encapsulation" has two related, widely used meanings:
information hiding, and scoping together functions and the data they operate
on, which I don't have a good name for besides "encapsulation." And there
are many kinds of polymorphism, but only one is emphasized in OO. So the
list becomes:

  inheritance
  information hiding
  encapsulation
  subtyping polymorphism

Inheritance is a mechanism for code reuse, and that's a good thing. It is however a somewhat brittle mechanism, and over time the OO consensus has been moving away from inheritance.

Information hiding in the OO sense is a good idea because it permits limiting the scope of updates, which allows some centralization in the manual enforcement of data integrity. Once a field is private, it can only be modified within a single class, and so you only have one class's worth of code to look at to see all the ways that field can be modified. However, a distinctly superior mechanism exists in the form of declarative integrity constraints. The reason this is superior is that being declarative rather than procedural, it is easier to get right: you only have to state what must not happen, rather than think of all the ways and all the places that might happen. Once you have declarative integrity constraints, the whole concept of public vs. private seems quaint. However, until you've figured this out, SQL looks like it's moving backwards because it doesn't have private.

I have nothing much to say about bundling types and methods.

Now, polymorphism is simply great. However subtyping is perhaps the least interesting kind of polymorphism, with parametric polymorphism being more powerful and general. Interfaces in Java are quite useful, however a number of authors have commented on its limitations. Notably the lack of retroactive abstraction mechanisms. I think this can be particularly well addressed by the use of a structural type system such as SQL has, rather than a nominal one such as most OO languages have. (OCaml being I believe the notable counterexample.) This also gets in to all kinds of issues around union types that I'm still thinking about.

Anyway, just some thoughts.

Marshall Received on Fri Dec 22 2006 - 19:59:36 CET