Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!travelers.mail.cornell.edu!news.kei.com!world!mv!usenet
From: rapp@lmr.com (L. M. Rappaport)
Subject: Re: Fat Objects
Message-ID: <DH222q.8G9@mv.mv.com>
Nntp-Posting-Host: lmr.com
Sender: usenet@mv.mv.com (Paul Hurley)
Organization: L. M. Rappaport & Associates, Inc.
Date: Thu, 26 Oct 1995 12:09:52 GMT
References: <230352Z25101995@anon.penet.fi> <46mkub$oq5@ixnews7.ix.netcom.com>
X-Newsreader: Forte Agent .99b.112
Lines: 32

novacasa@ix.netcom.com (Carlos A. Casanova) wrote (with possible
editing):

>>There was a discussion in August of "fat objects", which I understood to be 
>>objects with (too) many instance variables.  So I'd like to ask a specific 
>>design question regarding fat objects.
>
>>For example, if one were to implement a payroll system in ST, one would be 
>>faced with how to define the data structure/record/object for the Employee. 
>> The data items for an Employee can easily run into the hundreds.  Some of 
>>them can be grouped, e.g., name and address, Quarter-to-Date totals, 
>>Year-to-Date totals, etc.
>
>>Would it make sense to do it this way?  What are the alternatives - hundreds 
>>of accessor methods?  I'd appreciate hearing from someone who's successfully 
>>faced such a  fat object. Thanks in advance.
>
>
>The only time that I have seen 'FAT' objects have been in poorly
>designed systems.  For the most part you can usually find some common
>thread(s) among the data to justify creating a dependant object(s).

I don't understand - even if you delegate, you still need access to
all the attributes.  I don't really see "hundreds" there, but in any
complex accounting class, such as an employee payroll class, there are
going to be a lot of attributes, even if those attributes refer to
delegated classes.  What is your alternative?  Or maybe I simply don't
understand the question :) 

Larry
--

