Home > Messages from the Ether > Anti-objectivists

Anti-objectivists

Am I insane?

I recently sat through a rant against OOD because of its (1) over-abstraction and (2) inefficiency. The ranter in question was seething over some guy that was in love with his own code because he designed detailed object relationships. It's tough to argue about code you haven't seen, a coder you don't know, and all of this in relation to a common ailment with coders. I'll only relate this as a simile, but it's like impugning an artist for being in love with their own work. That's a given. However, that being said, I've heard too often that OOD is anathema.

My simplest argument for OOD comes with a refactoring task I perform at least once a day, I swear. It's the very basic Extract Class refactoring and is used to fix bloated classes that are 10k+ lines long and contain within them five to 10 different functional roles. One of those roles may consist of several functions and a few state variables turned into either parameters cascaded across each function or (more likely) superfluous member variables. All of that should be extracted into a separate class. The reasons for extraction are:

• Simplify the original class by removing utility code. It is easier to manage multiple 1k-line class than a single 10k-line class.
• Expect reusability. This is not to suggest that you're writing a library for the C++ standards committee (one of the ranter's accusations), but that another section of your project might need that code in isolation.
• Separate unrelated code so that when a programmer is updating one module, they do not lock more code than they need to.

These are all minor benefits, yet they take little effort to accomplish. The only downside is that pure project line-count will increase because of the extra class header definitions. This may increase compile time (especially if templates are used) and even run time; the latter would only be an issue in high-performance situations. Both speed issues are brought up by anti-objectivists regardless of whether the code in question even needs to be fast. And, of course, you should never optimize [Wikipedia] prematurely anyway.

Another complaint about OOD is that the functionality is spread throughout different files. Being accustomed to paging up and down through a single, large function to examine everything that it does, the anti-objectivists resist having to look from class to class, file to file. The benefits of breaking up code in such a manner are well-documented and not unique to OO languages. C projects should be broken up into modules to acheive similar benefits (thus the famous joke about OOD being "old news"). The only drawback, as stated above, is if speed is an issue and dereferencing either objects or functions are the source of the inefficiency.

OOD is not just a tool of academia, designed for ivory tower programming. It's used, and is useful, in the Real World.