From: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
---|---|
To: | cbbrowne(at)cbbrowne(dot)com |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, Curt Sampson <cjs(at)cynic(dot)net>, PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inheritance |
Date: | 2002-09-06 15:27:26 |
Message-ID: | 1031326047.18470.139.camel@mouse.copelandconsulting.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2002-09-06 at 08:57, cbbrowne(at)cbbrowne(dot)com wrote:
> > On Fri, 2002-09-06 at 07:37, Curt Sampson wrote:
> > > On 5 Sep 2002, Hannu Krosing wrote:
> >
> > To elaborate on Gregs example if you have table GOODS and under it a
> > table CAMPAIGN_GOODS then you may place a general overridable constraint
> > valid_prices on GOODS which checks that you dont sell cheaper than you
> > bought, but you still want sell CAMPAIGN_GOODS under aquiring price, so
> > you override the constraint for CAMPAIGN_GOODS.
>
> What that tells me is that the constraint, valid_prices, shouldn't have been
> on GOODS in the first place. If it is not a legitimate constraint for the
> children, then it is not a legitimate constraint for the parent.
>
I don't agree with you on that point. This concept is common to many
OO-implementations. Unless you can come up with a powerful argument as
to why our "to-be" picture should never do this, I'm less than
convinced.
> In human inheritance, if you marry someone with "funny coloured skin," you
> don't get to choose that your children won't have "funny coloured skin."
> That's a pretty forcible "constraint." :-).
>
Fine, but that only works for YOUR specific example. In that example,
the color constraint should be non-virtual, meaning, the child should
not be able to change it. On the other hand, if I replace "human" with
"metal product", hopefully I won't be stuck with gun metal gray for
every derived product. Hopefully, somewhere along the lines, I'll be
able to override the parent's color constraint.
> > Or maybe it is better to just make the check function should be
> > dynamically dispatched, so the constraint will always hold, it just can
> > mean different things for different types.
>
> Or maybe if someone is doing an Object Oriented design, and making extensive
> use of inheritance, they'll need to apply constraints in a manner that allow
> them to be properly inherited.
The problem with that assumption is that there is normally nothing wrong
with having seemingly mutually exclusive sets of *business rules* for a
parent and child.
Greg
From | Date | Subject | |
---|---|---|---|
Next Message | snpe | 2002-09-06 15:53:48 | Re: JDBC 7.3 dev (Java 2 SDK 1.4.0) |
Previous Message | snpe | 2002-09-06 15:21:00 | Re: JDBC 7.3 dev (Java 2 SDK 1.4.0) |