The Promise of Code Re-Use

Back in the day, Object Oriented Programming (OOP) held out a great promise: code reuse and recycling. No more writing code and then having to reinvent the wheel, no more wondering how to do something you wrote code to do a few years back. The life of a programmer was going to be easy and glamorous from now on.

Turns out that didn’t happen. Promises like that almost never come true, and they sure didn’t in this case.

For one thing, you could write a bunch of straight functions and put them in a single file to achieve the same effect. Instant code re-use. We’d been doing that for years before OOP became a “thing” (though not as extensively back then).

The other thing is that programmers and organizations don’t always want to re-use code someone else’s written. They didn’t indent where you would want them to, they didn’t capitalize their variables right. Why did they do their loops that way? Why did they return that from the function? Etc. Then there is the “Not Invented Here” phenomenon, practiced by large corporations (Apple, Adobe and Microsoft come to mind) and the like. If it wasn’t invented, stolen or bought by us, we don’t want any part of it.

OOP certainly didn’t deliver on this, its chief promise.

The Supposed Advantages of OOP

I’m not a language geek, nor an authority on computer languages. I’ve coded in BASIC, Pascal, C, C++, FoxPro, Perl, Python, PHP and Javascript. I’ve studied a few other languages like APL, COBOL, Fortran and RPG. The following discussion springs from my knowledge of these languages, and others of their ilk. If you want to talk about Smalltalk, Lisp, Haskell or other more exotic languages, my assumptions may be off. So that’s why I limit the discussion to the assumptions underlying the languages I know.

The following are the chief supposed advantages of OOP.

• Encapsulation: Or, “how I hid all my data from the rest of my program”. This is a rather silly claim for OOP to make, though it is true. Inside an opaque object, the data is hidden from the rest of the program. However, the values inside of a function are also generally hidden from the rest of the program. Values which you want to persist across function calls are a little harder. They must often be in the global scope to be of use to all or a subset of the functions. Whereas, an object automatically persists and hides values as designated by the programmer. So this is one aspect of OOP which could legitimately be considered an advantage. I talk more about this later.

• Abstraction: “the act of representing essential features without including the background details or explanations”. Translation: it’s a black box. Function black boxes do the same thing, more or less. Read the function’s code or not. But a function is typically guaranteed to have X inputs and Y outputs, just as a class method or object does. You can tear up and rebuild its insides, but as long as you don’t tamper with its “signature”. Just like-- surprise!-- an object.

  I’ll say one more thing about this. I’m not an enthusiastic fan of abstraction in the first place. It can quickly get out of hand. A programmer is better off the closer he is to the actual data and tools being used on his data. For example, it can happen that certain functions or methods are very expensive memory and time-wise. A programmer who is oblivious to this due to the multiple layers of abstraction in his code may not realize it. It could be that the code can be rewritten to eliminate this expense, but without the programmer knowing what’s going on at the "bare metal" level, he won’t know this should be done.

  As an example of the above, let’s say there are a set of rarely changing configuration values in the backing store. These values are needed for almost every function/method in the program. In badly written code, these values are fetched from backing store every time the programmer needs them. And since most functions/methods need them, this leads to a lot of wasted fetch time. If the programmer is aware of this fact, he can write one routine to grab these values, and either hold them in the pool of global variables (visible to all functions) or the internal values of objects, where they’re available to all methods at all times. But the more abstraction in the code, the greater the chance that he doesn’t realize this time-waster is sitting in his road.

  I wrote an automatic class instantiator one time, which would instantiate or call the singleton of a class, depending on the details originally fed into the instantiator. It worked fine, but it abstracted class instantiation so far that, in testing, it was nearly impossible to determine what class objects were present at any given time. The abstraction became a curse in testing. And although it worked well, I eventually ripped it out in favor of discrete object creations.

• Inheritance: This is pretty much a novelty more than anything else. You can build a new class that inherits features from an original “parent” class. Nifty. Do you mean to say you can’t do the same with a set of straight functions? Including calls to another function inside a new function can achieve the same effect. No reason not to do that. So why do we need a new paradigm for this?

  The classic example of this is something like the point, circle and sphere. The class hierarchy starts out with a point and its methods. The circle inherits characteristics from the point, and the sphere class inherits characteristics (and methods) from the circle. Fair enough, and not a bad selling point for objects and classes. However, selling OOP on the basis of this implies it can’t be done otherwise. But the truth is that it can be done with straight functions as well. C has structures and PHP has arrays, both of which can hold a variety of values and such. Functions may be written so as to imitate the way this is done in the OOP world. And in fact, this is what was done before OOP became popular. It’s not that hard, though perhaps easier with OOP.

• Polymorphism: This is an intriguing idea, and I’ll admit I once thought it was a cool aspect of C++. You could code a string object, and then if you wanted to add another string onto the end of it, you could just put a plus sign (+) between the two, just like if they were numbers. Because addition in the math world is more or less the same thing as concatenation in the string world. You can do things with this that make it look like you’ve broken the rules of your programming language. However, even with objects, it can be a hard thing to code. Moreover, while you can do such things, it’s questionable whether it’s of much value to the programmer in the long run. Again, it’s novel. And it sounds like a good idea. But how much use there is for it is another matter. You can accomplish this same thing by other means. It just doesn’t seem as cool. In the case of our string class, you’d have to write a “concat” function and pass in your two “parent” strings, returning your concatenated string. Not as elegant, perhaps, but it would get the job done. And it wouldn’t look like you were breaking the rules of your language.

The real advantages of OOP

• Protecting data and remembering state: There is an aspect of object oriented programming which acts as an advantage for a programmer, but only on a narrow basis. Functions have virtually no knowledge of their environment (in most languages) or memory of state. You have to rely on global variables and whatever information gets passed to the function on the stack. This is fine as far as it goes. But what if you could store values for later use in all the functions which are related to each other? Encapsulation to the rescue. No passing a bunch of state information in on the stack. It’s just there in the background, waiting for the function to access it when needed. That is one of the advantages of object oriented programming. The object can store a near unlimited number of attributes and values which can be accessed by the methods of the object at will. And these values are inaccessible outside the object, unless you, the coder, make them visible in some way. So, for example, for an object which is supposed to draw a sphere, the color, diameter and spatial coordinates of the sphere can reside inside the object, unreachable directly by the program, but available to every method inside the object. The coder does not have to pass these attributes into the “draw” method every time he wants to draw the sphere. Other methods, like “shrink”, “expand” and “move” can also use these values. This is a pretty good benefit for the programmer.
• Decluttering name spaces: Name spaces can get cluttered. It can happen with C libraries, with PHP code, and many other languages. I say this can happen, but I’ll also stipulate that it’s far more likely to happen in a language like C, where masses of code stay memory resident in memory for long stretches of time. In a language like PHP, the memory-resident code is far smaller and less likely to intersect with library code also in memory. If code re-use were really that prevalent, you’d run into it a lot more. You’d end up writing functions which had, coincidentally, the same routine names as those in code libraries from other sources. I’ve seen this happen in procedural code. Object oriented code allows us to name methods as we’d like, which method names can be exactly the same as those outside the object. Thus, an “add” method can be named so in both sphere and cube objects without fear of confusion or error. You can’t do that in non-OOP code, unless you use namespaces, which is only a recent addition, to, say, PHP (and one I’m not fond of). So this is another, and as far as I can tell the only other advantage of OOP.

I’m not particularly a Luddite or someone who likes to disagree just to stir the pot. Quite the opposite, in fact. I’m also a programmer who is painfully aware of the potential for over-use and waste of computer CPU time and memory. So, for example, on a PHP program intended to show a single screen with a form on it, I can’t see a reason to call in 150 code files, 20 calls to backing store, and a partridge in a pear tree in the process of displaying that one page. If I see that happening, I know I need to refactor my code. And I don’t much care for unwarranted hype. And I still see a lot of unwarranted hype around OOP. Even after years of experience which disprove most of the claimed benefits of OOP. I also don’t mind digging into code with both hands and feet, if necessary, if I think the code is too abstracted from the data and objects it represents.

Don’t get me wrong. I use classes and objects all the time in my PHP programming. But I use them primarily for the two main benefits I cite above. Otherwise, OOP isn’t of much use to me. I’m a practical guy, and pie-in-the-sky claims don’t impress me. Show me the code.