Archive for January, 2010

A Compelling Case For the Use of Objects

Thursday, January 7th, 2010

I think one of the hardest things about being a programmer is working with code that you’re not familiar with. You can spend hours, days, weeks, months, trying to understand the code that someone else wrote. I used to think that if a person who can’t read through my code and fully understand what my code is trying to accomplish, they have no right to call themselves a programmer. It wasn’t too long before I realized that my belief was wrong. To be a good developer not only do you need to be able to finish a project according to specifications, it must be well-written, and maintainable by others.

By maintenance, it means that a new comer can quickly figure out what’s going on without costing him a lot of time. Maintainability can be accomplished in many ways. From the way the code is structured, the way it’s documented, to training, and etc. Today, I plan on discussing code structure.

I’ve seen enough code to fear arrays that are pretty much the member variables of a object. Except all those member variables have been consolidated into a single array, and that single array is populated by a single function at run-time. This is a surprisingly common practice, I guess there are some up-sides to using this technique, the class that uses this technique will have less code involved, and code that calls this function would probably not change very much.

Now for the down-side. Someone down the line might find a need to modify the function, lets say “foobar”, so that it does more things with that data. Then somewhere down the road, someone else decides to make the array multi-dimensional, and then someone else somewhere down the line decides to make the foobar function handle the multi-dimensional array in multiple ways. You can explicitly tell programmers verbally or through documentation to use a single-dimensional array, but more times than not, things simply won’t go as planned.

With objects, you can create the function to handle a specific object type, through strict-typing. That type will have certain member variables set, which you can always rely on. It will be the same consistent structure, no matter what. This way, you’ll save yourself from dealing with function parameter input fowl ups.

What if you required the unique functionality of the multi-dimensional arrays? There are many ways to go about it. You could create a different class that extends the class that contains foobar. Although, that function would most likely need to be redefined. One example of a possible redefinition is to have the new foobar function take in the multi-dimension array you provide, but create the objects required by the parent foobar function and handle the result accordingly. The code for the class that performs foobar using objects and foobar using multi-dimensional arrays remain separate. You can alter the code to handle the various situations accordingly, if the functionality for multi-dimension foobar changes, you only have to alter the multi-dimensional array version. It might take more lines of code and more time, but when you revisit the code, even after a long period of time, you’ll find it very easy to maintain because all the logic has been keep separate. Each class, each function, all the various interacting components serve a very narrow and specific purpose.

I might add some code examples to illustrate the point at a later time.