Just what is an OOP? (to MOP or not to MOP)  

Herein lies a lengthy-yet-descriptive explanation of the difference between OOP (Object Oriented Programming) and non-OOP usage. Read only if you would like to educate yourself.

To better understand the relative benefits and shortcomings of OOP, consider the following: think of a program that you write as a factory. In this case, your factory is a place that takes in resources (the “input”), and turns them into some kind of practical product (the “output”). To better understand the difference between OOP and non-OOP paradigms, imagine a factory—let’s say, a car factory. Consider the early days of the conveyor belt, when the factory consisted more or less of a single conveyor belt moving through a long, straight building. For our purposes, we will assume that this factory is assembling the car from pre-manufactured parts.

Let us, then, follow our car on its journey of creation. Thus we will see pieces being added one by one: first the chassis is placed on the belt, then along come the seats that get bolted into place, then the steering wheel, the dashboard console, etc. After some time, our car begins to take shape. We have a cabin, and then an engine, and as we travel, we find our car is near completion. And at each station along its way, some machines or humans took up the task of attaching each piece to the chassis. And finally, at the end of the conveyor, an assembled car roles off the track and is ready to be utilized for its next purpose.

Such is the nature of a non-OOP paradigm; the program (the factory) is fed an input (a car-chassis), and as the input passes from point to point, operations are performed on it, and perhaps unexpected steps must be taken if a flaw is discovered in the half-assembled vehicle, but in the end we come to some sort of finalé, so that a new chassis can be started. This idea is equivalent to the top-to-bottom parsing of compiled code; the input comes in, is processed by any necessary routines and methods, and then the resulting output is spat out at the completion of the code, so that the whole system may be run again. And of course, these systems may be quite complex, and highly nuanced, such that they can handle many different situations (in the factory analogy, one might think of a modern conveyor that has the ability to customize and adapt to various situations, such that many sorts of vehicles may be produced on one assembly line). But here’s the rub: what happens to the car after manufacturing?

In the non-OOP factory, the workers are focused solely on producing the cars, and once the vehicle has rolled off the assembly line, they don’t particularly care if anyone can actually use the product. And this is the vital concept. The assembly-line workers produce a vehicle according to their provided specs, and assume that any buyer of the vehicle will simply make do with the car as it is. And this is fine in many, if not most, coding situations, when all that is needed is to respond with an appropriate output depending on the relevant input.

And now comes a stretch, as we attempt to realize the power of the OOP. Let us now consider the world outside the factory: when a vehicle rolls off the assembly line, it must be moved to a car dealership, where it might be sold to the consumer (we will ignore the many other possible destinations for this discourse). This alone is straight forward enough, as it is a simple feat to pass the output from one script as the input for another. But here’s where the fun begins! Imagine, if you will, a vehicle dealership that specializes not just in cars, but also in trucks, and RVs, and busses, and other such motorized vehicles. All fairly similar, but each with certain unique characteristics. Now, if a man, let us call him Mr. Top comes to the dealership to purchase a vehicle, perhaps he comes focused on a car. To this end, he has done careful research, comparing cars online, and generally boning up on his car-purchasing knowledge. Yet when he arrives at the dealership, he is presented with a broad variety of vehicles when he sees all the other sorts that are available for purchase. Well, unequipped as he is to decide between vehicles larger than a car, he must make a decision: will he filter out everything except the cars, and limit his eventual possibility, or will he attempt to compare the larger vehicles to the cars.

Let us stop here for a moment to review this new metaphor, to draw some parallels to our coding. In this case, we see the dealership as a collection of data (the data in this sense being the “vehicles” produced by the “factory” code that we earlier established). How this data is stored is irrelevant; we need merely recognize that the “dealership” contains a large array of data to sort through, looking for a single perfect choice, which we will output to the “customer” program. However, in our chosen metaphor, the “customer” was only expecting to look at cars, and has become stumped by the variety of options available in terms of vehicle type. And now that we are caught up, let us return to our regularly scheduled metaphor.

Back at the car dealership, our Mr. Top has opted to compare all the various vehicles, to look for his perfect match, but comes up perfectly confused and lost as he tries to make something of the large variety of vehicles. And here is where we find a terrible shortcoming of non-OOP. When we look at the traditional top-to-bottom approach of manufacturing (i.e. a non-OOP paradigm), we find that each and every manufacturer of cars will create a different style of car. And just the same way, let us say that there is no standards committee controlling vehicle production, such that each manufacturer may decide what specifications to release about their vehicle. It is this flaw, this incompatibility between “factories” that makes object oriented programming so powerful. In traditional non-OOP paradigm, the output of a program is seen a plain data-structure. Internally to the program, or even to the programmers other scripts, this data-structure might be perfectly reliable and usable. But the problem comes when another programs asks to use the same data. More often than not, many such non-OOP “customer” programs will be tailored to expect only one sort of input, or else will be hand-coded to interpret only certain other data-structures. But in either case, the variety of interpretable data-structures is very limited. This is the analogy we examined previously, in which the “customer” has researched only certain varieties of cars, and as yet knows nothing what-so-ever of trucks, RVs, etc., and is thus stumped and, in terms of our program, gives up on the job entirely.

“So, then, how exactly is OOP different?” you might ask. Well, as long and convoluted as our previous analogy was, it lays the perfect groundwork for exploring the benefits of OOP. Once again, we focus in on our dealership; however, this time, we see a different patron. This one, Mr. Oop, is well read about all sorts of vehicles. But he does not know the specifics of each individual kind of car, truck, etc. Instead, he has studied the concepts of what makes a vehicle work. He knows about horsepower, and fuel economy, and life of the vehicle, and all the sorts of things that one should consider before purchasing. Instead of studying each car so that he can find exactly the one he wants, Mr. Oop has instead taught himself what defines an acceptable vehicle. Now, unlike the previous patron, our Mr. Oop can ask the dealership the relevant stats of each vehicle, such that he can compare them side-by-side, to sort them by any value he feels is important. In code, we call this functionality a protocol (or, in Java, we call it an interface). By any name, it is this ability to isolate and compare different objects that makes an OOP so powerful. And what is an object? Well, an object is merely an ordinary data-structure, but one that has been produced in a certain consistent format, that allows the “customer” to compare any structure that matches this format.

So you see, the essence of an Object is as simple as a set of standards that must be followed when creating a data-structure, and a label that declares what standard the structure was produced under. The exact system by which a program determines this metadata varies from language to language, and is called a MOP, or Metaobject Protocol.

Now, it must be clarified, many OOP-based scripts can become obfuscated by a failure to utilize existing standards, and by subpar documentation, but this is just as true of any sort of code. Furthermore, it must be noted that some non-OOP scripts utilize some sort of parsing system to interpret data-structures on the fly, but these are most always very simple methods intended to sort between a few specific formats of input.

Whew, almost done! Finally, let us address encapsulation. The ability of an object to contain its own interpreter is one of the single most powerful parts of the OOP paradigm. Encapsulation is the term used to describe the ability of an object to access, change, or merely view its own data values. This typically breaks down into a set of specialized routines called “”, whose job is to return simple data-values to a program that otherwise might not know how to interpret the object. These methods could return numbers, strings, arrays, or any other sort of data-structure that the programmer wished to return to the “caller” that asked for said data. Moreover, these mutators can even return whole objects, such that an object can contain many sub-objects. Essentially, the object itself can contain a whole host of information, within easy access, that might otherwise require numerous scripts to access from within a program. And, through various concepts such as abstracting and interfacing, a set of objects can be built such that they all rely on a single list of a mutators, such that one program may access untold vaults of data with a few simple lines, knowing that each object will understand the same commands.

But now I am turning toward a more detailed explanation of OOP, and if you have made it this far already, I will trust that you, dear reader, will be willing to continue to research on your own.

N.B.
As we draw this lengthy lesson to a close, please do be aware that I have only brushed on the true power of OOP, and moreover I have not attempted at all to indicate when one should make us of OOP vs. non-OOP practices, as this decision will vary on a case-by-case basis. My purpose here is merely to highlight the differences in purpose and ability of the two paradigms. To learn more, I highly suggest researching the topic of encapsulation, as well as that of overhead code, as these two subjects will illuminate in much greater detail many advantages and disadvantages of OOP.