Re: Clean Object Class Design -- What is it?

Lee --

If it interests you, I'd like to work with you off-line from the group to show you how I'd actually design this using objects and an OODBMS. Whatever design we come up with, I will repost to this group so everyone may see how these things work.

Let me know.

Regards,
Jeffrey D. Panici
Worker Bee Solutions, Inc.

"Lee Fesperman" <firstsql_at_ix.netcom.com> wrote in message news:3B3FD5BB.56E8_at_ix.netcom.com...
> Jeffrey D. Panici wrote:
> >
> > Bob --
> >
> > First, let me set the stage: The key difference between OO/AD and pure
 data
> > modelling isn't the data at all, it is the behaviour. Look: While one
> > could argue that a "table" in the relational world is a form of data
> > encapsulation, and -- may god strike me down for saying this -- the
 stored
> > procedure is a form of encapsulating the "behaviour" associated with
 these
> > encapsulated data bits, it is a very weak link at best.
> >
> > ..........
>
> That was a very passionate (and well thought-out) argument for associating
 behavior with
> data through OO. It was almost convincing.
>
> This approach can work well when you have a single, standalone
 application. However, in
> the real world, you usually have multiple disparate applications that wish
 to use the
> same data.
>
> Let me use an (abstract) example --- a business entity. This entity has
 scheduled
> processing:
> + daily
> + weekly
> + monthly
> + quarterly
> + yearly
> + standard reports
>
> ... and unscheduled processing:
> + maintenance
> + ad-hoc reports
> + ...
>
> Note: There may be little relationship between the different activities.
 If the entity
> was an employee, it could be: daily - timesheet reporting, weekly -
 project status,
> monthly - payroll, quarterly - job review, ...
>
> Each activity can have its own special view of the data and specialized
 behavior. The
> activities may be performed on behalf of different departments in a
 company.
>
> Do we clump all this behavior into a single object? I think that would be
 a maintenance
> nightmare. You could use inheritance, but in most OO languages inheritance
 is at the
> class level --- you can't take a persistent object at run-time and extend
 it by
> inheritance.
>
> You are left with dynamic 'composition' of objects --- which means you
 make a common
> object that can be shared. I have doubts this can be accomplished using OO
 techniques. I
> have no doubt it can be accomplished using relational techniques (like
 normalization).
>
> --
> Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
> ===================================================================
> * Check out Database Debunkings (http://www.firstsql.com/dbdebunk/)
> * "The Forum Where Database Matters Are Set Straight"
Received on Sun Jul 22 2001 - 01:33:14 CEST