Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsfeed.cit.cornell.edu!newsstand.cit.cornell.edu!travelers.mail.cornell.edu!news.kei.com!news.mathworks.com!newsfeed.internetmci.com!howland.reston.ans.net!ix.netcom.com!netcom.com!sehyo
From: sehyo@netcom.com (Sehyo Chang)
Subject: Re: Fat Objects
Message-ID: <sehyoDH4I02.G85@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <230352Z25101995@anon.penet.fi>
Date: Fri, 27 Oct 1995 19:55:14 GMT
Lines: 31
Sender: sehyo@netcom20.netcom.com

The Unknown Ranger (an397723@anon.penet.fi) wrote:



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


There are couple of points;

If you are starting from legacy system, you are often stuck with emulating
their database structure unless you get to restructure(nil chance) it.

However, if you are starting from scratch, I don't see how you come up with
"fat" objects unless you have done bad modeling.  My "rule of thumb" is 
having more than 20-25 instance variables are way too big. Key is find
proper abstraction, find "intrinsic" attributes that belong the to objects
not ancilliary ones, use "role modeling",etc.

-- sehyo
