Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: erk <eric.kaun_at_gmail.com>
Date: 21 Jun 2006 12:48:40 -0700
Message-ID: <1150919320.443106.27930_at_i40g2000cwc.googlegroups.com>


Robert Martin wrote:
> On 2006-06-13 09:32:58 -0400, "erk" <eric.kaun_at_gmail.com> said:
> > If the language itself included the ability to define relations and
> > constraints (and obviously keep those in sync with the DBMS), this
> > would be equally easy.
>
> True. However, our languages don't seem to be moving in that direction.
> Nor am I convinced that they should. While RM is a powerful technique
> for structuring data, I am not convinced that it is a powerful
> technique for structuring behavior.

No, it's not - it concerns constraints on behavior (preventing your database from becoming a free-for-all, or more generously just accumulating subtle data anomalies). Functional languages are far better for such things. I just think (after 8 years of O-O, beginning with being a true enthusiast) that coupling data and behavior hobbles both - although it's true that languages like Lisp and Smalltalk, that give you higher-level functional behavior, ameliorate that. For an example of what Java could have been (though it's not enough), look at Nice. I can't comment on C++, having never used it for anything functional.

> Render unto Ceasar. I have no problem with integrity rules being
> enforced by the database so long as they do not interfere with the
> testability of the application. However, any *application specific*
> constraints should be managed by the application instead of the
> database.

Agreed; I just don't think there are many of this breed. Most

> >> I disagree. Striving to separate your application into database
> >> dependent and database independent partitions enhances flexibility and
> >> testability, without reducing power.
> >
> > Would having easier-to-use DBMSs, even in-memory ones, do the same for
> > you?
>
> No, I value the separation for it's own sake, not because of any
> particular tool.

OK, then our values simply differ. Separation has a cost, of course, and separating an application which manipulates data from the canonical definition of that data seems to me like a mistake, other than as a simple ADT implementation technique.  

  • erk
Received on Wed Jun 21 2006 - 21:48:40 CEST

Original text of this message