Ed Gibbs has an article entitled Spaghetti OOs Code in which he talks about a conversation he had with his brother about “too many objects” vs. more “meaty” objects and it reminded me of a position I was in once, and hopefully a lesson that makes sense.

I’ve always ahered to the idea to have enough objects to get things done in an understandable way, without having 4000 objects to keep track of in order to get something done. I’ve seen many applications written where there are several layers of indirection that you have to traverse in order to figure out whats going on, as you have objects that perform certain actions on other objects such as rendering its contents as HTML or XML. These would all be great if they worked on a base class of the actual object being rendered, however they work on specific derivitives, requiring a reimplementation of a rendering object for each specialization of the original object.

Here’s an example. I worked at a place once that had a general rule (big red flag here) that each piece of functionality had to be made up of four separate components:

DA (Data Access)

This object was responsible for retrieving data from a database or other data source.

BO (Business Object)

This object was normally a result of retrieving data through the DA object and represented a business object.

BS (Business Service)

This object was responsible for performing services related to the BO.

BA (Business Access Object?)

I know we had something called a BA, but I can’t remember what it was used for (second red flag). However, it was a required component.

These components had no base classes or framework around them (third red flag), they were just required components that had to be used. Now, for some, this doesn’t seem like a big deal, but try writing some simple code that renders a pulldown in HTML off of a database query and then multiply that work by 10 and you’ll see where this becomes problematic. No framework in place, but all objects were required.

When I first came on, I had to write code that rendered a pulldown box in HTML and I wrote something like the following (Editors note: This was written to illustrate a point and most likely will not execute – its been a while since I’ve written Java):


/**
* Yes, this should or could have been an interface. I was a beginning java programmer at the time, coming from C++ - so
* this made much more sense to me at the time!
*/
public abstract class PulldownData {
/**
* Generate a hash table from a query in which the keys are the select values and the values are the descriptions to appear
* in the pulldown
*/
public abstract Hashtable getData();
}

strHTML.append("");
}
}
return(strHTML.toString());
}


Once this framework was completed, all you had to do to create a new combo box was to derive a new class from the PulldownData object and pass this object to an instance of the PulldownRenderer class and voila! You had a pulldown!

Despite the decrease in actual work involved, I actually spent quite a bit of time arguing why this was a better approach than having four tightly coupled objects that could not be reused to render my combo box with an “architect” that was on staff at the time. I had violated the “general rule” and written something simple and useable.

All of this was written just to illustrate a point. The simpler the better. If you are decomposing things into 500 objects because “thats the way we do it” or “everything else here is written that way”, you are doing it for the wrong reasons. There has to be a reason to decompose things to a level that makes sense for the person coming after you, or the people you are working with. Object orientation has the ability to make your job a hell of a lot easier, but its a two edged sword. It can also make your life extremely difficult if you ignore the KISS principle and abstract for the sake of abstraction.