Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsfeed.cit.cornell.edu!newsstand.cit.cornell.edu!news.kei.com!newsfeed.internetmci.com!in2.uu.net!hodes.com!netcomsv!uu4news.netcom.com!netcomsv!uu3news.netcom.com!ix.netcom.com!netcom.com!rfenney.slip.netcom.com!user
From: rfenney@directnet.com (Robert J. Fenney)
Subject: Re: Fat Objects
Message-ID: <rfenney-311095203415@rfenney.slip.netcom.com>
Followup-To: comp.lang.smalltalk
Sender: netnews@mork.netcom.com
Nntp-Posting-Host: rfenney.slip.netcom.com
Organization: FenTek
References: <230352Z25101995@anon.penet.fi> <sehyoDH4I02.G85@netcom.com>
Date: Wed, 1 Nov 1995 03:37:28 GMT
Lines: 44

In article <sehyoDH4I02.G85@netcom.com>, sehyo@netcom.com (Sehyo Chang)
wrote:

> 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

Even new designs that model enterprise objects can sometimes be quite
large. I have a class that has 200+ attributes. Another area that tends
twards large classes sometimes is data warehousing. These kind of classes
and not 'FAT' even though they have a high number of attributes, put
another way: if each attribute in a class definition serves a usefull
perpose and there is no advantage in refatoring, leave it alone and move on
to a new problem.

Robert
