Re: Principle of Orthogonal Design

On Jan 22, 7:07 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Brian Selzer" <br..._at_selzer-software.com> wrote in message
>
> news:h_mlj.1632$so6.1229_at_newssvr19.news.prodigy.net...
>
>
>
> > "Brian Selzer" <br..._at_selzer-software.com> wrote in message
> >news:nM9lj.2189$Rg1.958_at_nlpi068.nbdc.sbc.com...
>
> > > "David Cressey" <cresse..._at_verizon.net> wrote in message
> > >news:wA2lj.4389$YH6.1499_at_trndny03...
>
> > >> "Brian Selzer" <br..._at_selzer-software.com> wrote in message
> > >>news:kO1lj.2507$nK5.335_at_nlpi069.nbdc.sbc.com...
>
> > >>> I think that there are times when it makes sense to 'collectivize'
> under
> > >>> a
> > >>> single predicate, and there are times when it does not. In
> particular,
> > >>> if
> > >>> the individuals represented are just different kinds of the same sort
> of
> > >>> thing, such as is the case with the different kinds of phone numbers,
> > >>> then
> > >>> it makes sense to 'collectivize' those attributes that are common to
> all
> > >> of
> > >>> those individuals under a single predicate. If, on the other hand,
> the
> > >>> individuals represented are different sorts of things that just happen
> > >>> to
> > >>> have the same attributes, then it doesn't. A disjunctive
> > >>> predicate--something like, for example, each tuple exemplifies an
> > >> individual
> > >>> that is an X or a Y, just doesn't make any sense to me. A conjunctive
> > >>> predicate on the other hand--for a relation that has multiple keys,
> for
> > >>> example--is not a problem since each tuple would exemplify an
> individual
> > >>> that is /both/ an X /and/ a Y. So if the predicate can be stated so
> > >>> that
> > >> it
> > >>> is not disjunctive, then 'collectivizing' is to be preferred.
>
> > >> It seems to me that you are describing the
>
> generalization-specialization
>
>
>
> > >> pattern.
> > >> Am I reading you right?
>
> > > Not exactly. For example, some serialized parts have a lot number; some
> > > serialized parts have a lot number and an expiration date; some
> serialized
> > > parts have a location in the warehouse (those that haven't already been
> > > shipped); but all serialized parts have a cost. So there could be the
> > > relations,
>
> > > R1 {Part#, Serial#, Cost}
> > > R2 {Part#, Serial#, Warehouse, Bin, Cost},
> > > R3 {Part#, Serial#, Lot#, Cost}, and
> > > R4 {Part#, Serial#, Lot#, ExpirationDate, Cost},
>
> > > where {Part#, Serial#} is the key for each and
>
> > > IS_EMPTY( R1 JOIN R2 {Part#, Serial#}) AND
> > > IS_EMPTY(R1 JOIN R3 {Part#, Serial#}) AND
> > > IS_EMPTY(R1 JOIN R4 {Part#, Serial#}} AND
> > > IS_EMPTY( R3 JOIN R4 {Part#, Serial#})
>
> > Sorry about that, I hit send before I had completed my thought.
>
> > It's not exactly specialization/generalization--at least not in the OO
> > sense--because a serialized part is still a serialized part regardless of
> > whether it is located in the warehouse or not.
>
> I intended generalization/specialization in the data modeling sense. I
> think the OO sense is just about the same thing, but I'm not sure.
>
> I don't understand your example about serialized parts.
>
> But "home phone number // work phone number" sure looks like gen-spec to
> me.
> "phone number" is data that can be applied to a "telephone" generically.
> a "home phone" is a specialized phone. (Actually, it isn't the telephone,
> but the telephone line or more specifically the associated service contract,
> that is peculiar to either home or work).

Keep your dastardly OO away from my query neutral data, and leave it in Smalltalk where it belongs ;)

Given:

- Frank's home telephone number is X
- Franks work telephone number is Y
- Tom's home telphone number is Z

How does one build the true(TM) generalization/specialization pattern?

- numbers -> home numbers -> franks home numbers
- numbers -> franks numbers -> franks home numbers
- franks contacts -> franks contact numbers -> franks home contact

Or is in fact X a number wrapper object implementing "telephone info", "home info" and "franks info" interfaces? Or should I be employing some form of policy based OO? Or has in fact the world gone completely mad? Confucius, he say, Jim has no answers, only questions. Received on Tue Jan 22 2008 - 21:21:58 CET