From: Joseph Bacanskas Subject: Re: Clean Object Class Design -- What is it? Newsgroups: comp.databases,comp.databases.object,comp.databases.theory,comp.lang.java.databases,comp.lang.java.programmer Followup-To: comp.databases References: <9hjie6$s3a$1@flood.xnet.com> <3B3FD5BB.56E8@ix.netcom.com> Lines: 73 User-Agent: KNode/0.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Message-ID: NNTP-Posting-Host: onlyNews customer X-Complaints-To: abuse@onlynews.com X-Trace: onlyNews customer NNTP-Posting-Date: Sat, 21 Jul 2001 16:32:49 PDT Organization: www.onlynews.com Date: Sat, 21 Jul 2001 23:32:49 GMT 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.