Message-ID: <230352Z25101995@anon.penet.fi>
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!travelers.mail.cornell.edu!news.kei.com!news.mathworks.com!newsfeed.internetmci.com!EU.net!news.eunet.fi!anon.penet.fi
Newsgroups: comp.lang.smalltalk
From: an397723@anon.penet.fi (The Unknown Ranger)
X-Anonymously-To: comp.lang.smalltalk
Organization: Anonymous forwarding service
Reply-To: an397723@anon.penet.fi
Date: Wed, 25 Oct 1995 22:58:22 UTC
Subject: Fat Objects
Lines: 23




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.


--****ATTENTION****--****ATTENTION****--****ATTENTION****--***ATTENTION***
Your e-mail reply to this message WILL be *automatically* ANONYMIZED.
Please, report inappropriate use to                abuse@anon.penet.fi
For information (incl. non-anon reply) write to    help@anon.penet.fi
If you have any problems, address them to          admin@anon.penet.fi
