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_at_news1.sttls1.wa.home.com>
>
> 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).
>
Date: Sat, 21 Jul 2001 23:32:49 GMT
Message-ID: <crR%6.282102$p33.5656678_at_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 Sun Jul 22 2001 - 01:32:49 CEST