Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

private Hashtable properties

Hey all,

Thanks for the responses to my previous post.  I am now modeling a class that will have at least 44 different attributes.  These attributes could potentially change over time.
My inclination is to model these attributes as a private Hashtable and then use GetAttribute(key) and SetAttribute(key, value) as accessors for individual attribute values.
I know this does very little for the encapsulation effort but I'm wondering if there is a better way to account for potential changes to the attributes.  I could probably write accessors in the SetAttribute method to check for any values that are more precarious.

Eager to hear input -

David Seruyange
Wednesday, September 25, 2002


Could you possibly provide a list of these attributes?  With that many, there's a good chance that some of them could be grouped into data objects.

John Barnette
Wednesday, September 25, 2002

Well, it's a loan application for a bank which includes demographic information (addressinfo etc...), bank information (acct #s, etc...), employer info(name, address etc...)

I could separate these into multiple classes but that wouldn't help me as the data could change at any point (hm, unless I generated an interface for each - there is a thought).

Right now I have the following:

public interface IChangeableProperties{
private Hashtable Properties
public void getProperty(key);
public void setProperty(key, value);
public String[] getMultipleProperties(String[] keys);

I derive more than a few classes from this at this point.

David Seruyange
Wednesday, September 25, 2002

What's going to change about an Address?

Why not break them up into interfaces ... an Address interface with Street Address/State/Zip, etc.

The problem with using a "bucket of properties" is that you lose all ability to have the compiler check things for you intelligently. In the simplest possible example

x.FulName = "Kermit the Frog"; <- generates a compiler error because FulName is spelled wrong

Set("FulName","Kermit the Frog"); <- doesn't.

Joel Spolsky
Wednesday, September 25, 2002

Point well taken Joel.  The reason I was loathe to model even addresses is that there are different types of addresses and different numbers of addresses applied to each loan applicant.

I suppose I could have an array of such mini objects and use containment to put them all together in a loan application.

Regarding the compile error issue you mentioned, remember that I'm shadowing the Hashtable, not using it directly.  Calls to get/set values will include a check using the ContainsKey method as follows:

string getValue(string key){

return hash(key);
throw new InvalidPropertyException("Invalid Property!");


Wow -- something for my blog; JoelOnSoftware responded to *my* post. =)

David Seruyange
Wednesday, September 25, 2002

To a certain degree the flexibility you desire is great for quick and dirty apps-- but it doesn't do much when you're developing in an OO environment. You've just got to suck it up, do the design work, and lay down the law.

OTOH, did you ever think of using a DataSet to model some of your data? You can develop schemas to ensure integrity.

I'd equate developing components around a hashtable bucket with inventing today's high-tolerance HTML. It seemed like a good idea at the time...

Friday, September 27, 2002


Seems like you'd have type problems too. What if somebody did this?


If I were in your situation, I'd probably use a typed dataset.

They're easy enough to change if your data changes.

Luke Duff
Friday, September 27, 2002

How do you plan to implement the 'different types of addresses and different numbers of addresses' you mentioned for each loan applicant using your scheme?

key="Address1", value="123 Sesame St."
key="Address2", value="321 Sesame St."


As was already mentioned this kind of practice is very error prone and will bite you in the ass.

You can account for different types of addresses using inheritance and different number of addresses using a collection. A little design work will save you a lot of hassle.

Wednesday, October 2, 2002

*  Recent Topics

*  Fog Creek Home