Jan 7: Deep Simplicity Part 7

In this entry I am going to talk about rule #7: Don't Use Any Classes with More Than Two Instance Variables. This for me is one of the hardest rules to try to follow. The author of Deep Simplicity states that he is about to release a one hundred thousand line application that strictly follows these rules, so I guess I just suck.

The reason that we can break any object down to have one or two instance variables is because when you have more than two of them, you can usually group two into one object. Adhering to this rule makes for logical code that has a very defined responsibility. This after all is the whole point to these rules; making it so that everything is so simple it requires little to no thought to work on the project. Let's look at some code:

So we have all seen the classic User object, you might be wondering how we can get this object to have one or two instance variables. You can do it by either working your way down by splitting an object into related halves or working your way up by taking any to instance variables and making an object out of them. So let's try it:
So there we have it. The User object was broken down into finer grained objects that can then house the logic specific to those properties. It's pretty sweet when it works out that way, but in the interest of full disclosure I'll admit that I have no idea how to break up the original User class I was going to use for this example:
To me, that is more like the User objects I see all of the time. I can still break it up into Name and ContactInformation. ContactInformation can be broken down into Address and PhoneNumbers, but I can't think of a way to break up this object:
To me, every property in there belongs to an address. Further, I can't think of a way to group any two of these properties into a new object or a way to split this object in half. Can you see a way to split them? Feel free to comment about it.

Next time is rule #8: Use First Class Collections.
Posted by Matthew Purdon in Software Development Comment: (1) Trackbacks: (0)

Trackbacks
Trackback specific URI for this entry

No Trackbacks

Comments
Display comments as (Linear | Threaded)

#1 - Maggie Nelson said:
2009-01-08 10:00 - (Reply)

The Address class is too broad and too specific at the same time. I've always had issues with the fact that most Address classes in almost all cases are only made for USA addresses (and sometimes Canadian).

Here's a few of addresses:

123 Main St
New York, NY 10001
USA

123 Main St.
Suite 7
New York, NY 10001
USA

House 7
Village of the Damned
Transylvania

While there is a certain pattern here, there's really not that much in common. I would suggest that "address" is really just a string. Think of it as a phone number: even though it's made of digits, it's also a string - you're never going to do math on it.

I propose that your Address class is really this:

class Address
{
protected $stringRepresentation;
protected $geolocation;
}

So for human-readability or when you need to print a mailing label, just $address->stringRepresentation. When you want to do any address statistics, e.g. "how many people from town X like candy", you use geolocation to compile that data. Which means you now have a whole set of new (and also simple) Geolocation objects:

class Geolocation
{
protected longitude;
protected latitude;

// methods
}


I really like this approach of keeping objects very very simple because it really forces you to rethink what you actually know about your data. Maybe you will encounter a situation once in a while where you have to have 3 properties instead of 2, but that could/should be rare. But at least you get to see the red flags.


Add Comment

Standard emoticons like :-) and ;-) are converted to images.