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

From: Joseph Bacanskas <jbacanskas_at_home.com>
Date: Sat, 21 Jul 2001 23:32:49 GMT
Message-ID: <crR%6.282102$p33.5656678@news1.sttls1.wa.home.com>

Hi Lee:

In objectland, your description would imply a report object which would have the behaviors that, if I read you post correctly, you are assuming would be attributed to other domain objects. My guess from your description, is that the report object heirarchy would be quite rich. ;-)

There is no need to burden with reporting behavior the domain objects you describe. Better a reporting object that can work in concert with your domain objects to solve a very real system requirement.

Lee Fesperman wrote:

> 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).
>
 

-- 
Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.

Received on Sat Jul 21 2001 - 18:32:49 CDT