The Dark Side of Objects

The Dark Side of Objects?  (Luke, I am your father.) 

Sometimes you need reins on developers and designers.  Not because they aren’t doing a good job, but because if you don’t you may end up in a quagmire of objects that no one can understand. Objects are good, but they can be overdone.  Not everything should be an object and not everything lends itself to being objectified.  Sometimes a developers goes too deep when trying to create objects.

When I was learning about objects I had a great mentor who understood the real world boundaries of objects:  when to use them, how to use them and far to decompose them into additional objects.  Shortly after having "seen the light" with regard to objects I was helping a young man (okay, at my age everyone is young) write an application which was actually the sequel to the data entry application I mentioned in the previous note.  He needed to do some funky calculations so he created his own numeric objects.  Instead of using the built in Integer types he decided that he would create his own Number object.  This number object would have a collection of digits  When any calculations needed to be done he would tell one of the digits the operation to be performed and let that digit tell the other digits what to do.  Well, this gave him a method whereby he could perform any simple numeric operation (+-/*) on a number with a precision of his own choosing.  He spent weeks on perfecting this so that his number scheme could handle integers and floating point numbers of any size.  It was truly a work of art. 

And weeks of wasted time.

What he needed to do was multiple two numbers together or add up a series of numbers.  Nothing ever went beyond two decimal points of precision and no amount was greater than one million.  These are all functions built into the darn language and didn’t need to be enhanced or made better.  The developer got carried away with objects and objectified everything when it didn’t or in this case, shouldn’t have been done.

Knowing when to stop using objects is just as important as knowing when to use objects.


New Cobol

There is a phenomena that has risen in the last few years which, unfortunately, has had a detrimental effect on the IT industry. For the sake of simplicity, I shall call it the rise of New COBOL.

Now, some of you may not know what COBOL is, so a short history lesson is required. COBOL (COmmon Business-Oriented Language) was developed in 1959, primarily for use by the U.S. government. It quickly spread and became the de facto standard upon which billions of lines of code were written. It was also, almost single handedly, responsible for the boom in the IT business prior to Y2K because of the number of lines of code written in COBOL. While it has been criticized as verbose, it is capable of handling most business problems currently encountered and is a perfectly valid language for developing applications.

New COBOL, however, is something which people should not want. New COBOL is actually the use of an object oriented language in a procedural way. Most newer languages are object oriented in that business logic and data are encapsulated within an object and that interaction with that object is done through methods. When the developer discards the object oriented nature of the development language and essentially writes procedure COBOL, but in a new language, we have New COBOL.

This perversion of the intent of an OO language causes many problems, not the least of which is an increase in maintenance costs due to the barrier imposed in understanding the purpose of the underlying code. If the application was written in an OO style than a maintenance individual could understand it and make changes relatively quickly. If, however, the application was written in a procedural manner, but with an OO language, methods and data do not appear where they “should be”, resulting in a higher learning curve for the developer.

If you’ve chosen to develop in an OO language, make use of the facilities of that language. Failure to do so is a disservice to your client, as well as yourself.

I look forward to your comments on this one, as I know for a fact that certain architects disagree with my stance.