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

From: Lee Fesperman <firstsql_at_ix.netcom.com>
Date: Sat, 21 Jul 2001 23:32:47 GMT
Message-ID: <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:32:47 CEST

Original text of this message