OOP breaks the world of programming into modules that behave as black boxes, and this doesn’t mean airplane flight recorders.

A black box, in programming terminology, is any object that receives something as input, does something to that thing it’s received, and spits out a result. What’s going on inside the black box is anyone’s guess, but that’s okay, because you don’t need to know what’s happening inside to work with it.

As an example, consider your VCR or DVD player. You have (at least) a basic understanding of its operation: put some media in and watch a movie. However, you might not know all the details of how, precisely, that media yields up its information and has it transformed into patterns of light and shadow you interpret on your TV screen as being representations of real-world objects, such as buildings, people, or trees.

Furthermore, you don’t need to know. You do not have to have a degree in engineering to make a DVD player work, and you certainly don’t have to have an intimate understanding of helical-scan recording and playback, sync pulses, or the methods of encoding information magnetically to pop in a tape. All you really need to understand is a few simple interface controls in order to get all of this fabulously complicated technology to work for you.

This is a lot like what object-oriented programming principles do in the programmer’s world. They allow code objects to be produced that do rather complicated things with any data they have been passed, and then to return some kind of result; then they’re done.

What’s even more useful, though, about OOP code is that you can have multiple instances of the same code object in memory, each of which is responsible for performing related but discrete functions.

Think of pizza delivery. You call up the local pizza shop and ask them to create an instance of the object called pizza, medium sized, thick crust. You further instruct the shop to put green peppers, tomatoes, and mushrooms on this pizza thing. You then inform them of the location you wish to have the pizza result delivered.

It would be mad to assert that this pizza shop had come into being the moment you made contact with it, and it would be equally crazy to think that the pizza you just ordered will be exactly the same kind of pizza that everyone else wants. Therefore, the pizza shop is both persistent (it exists whether or not you’re calling it at any given moment) and capable of receiving parameters to modify its behavior (the pizza you ordered can be different from the pizzas ordered by others; in fact, there’s a wide range of different possible pizzas that can be ordered).

How OOP is Related to Other Kinds of Programming

The pizza shop example is analogous to the way object code works, like the VCR or DVD example. Since you’ve had some practical programming experience by now, you might think that it makes more sense to just write a handler that makes your pizza for you, and forget about all the fuss. You’d be correct, of course, because in this case a pizza is not especially complicated. It would probably take longer, in fact, to create the pizza-producing code object than it would to simply write a handler that did the pizza for you.

But consider expanding the pizza shop idea a little. Imagine a shop that still has the same phone number, but that also bakes lasagna, makes spaghetti, and produces sandwiches (both hot and cold) of various types. Suddenly, you are no longer looking at a simple pizza every time you call the shop; you’re looking at different types of possible food results entirely.

That would get a little more difficult to write as a single handler; you’d be happier breaking it into discrete handlers, one of which describes the kind of food, one of which handles just the pizzas, one for the lasagna, and so on. So much for your nice, simple little pizza shop!

That’s why you’d want to put this kind of code into an object. You would then have everything wrapped up into a neat little package and you’d still be able to work with it as though it were a very simple black box.

But even there you might argue the pizza shop isn’t all that complicated. However, I could counter with a shop that remembers the orders you’ve made recently and gives you a chance to do a "speed order," where you simply call without saying anything and hang up, and the shop immediately cranks out a duplicate of the last food item you ordered; further, this shop could intelligently interpret your gustatory needs and not send you a food object that’s larger than you can actually handle at one sitting. Pretty soon, the pizza shop becomes very complex and large, and might continue to expand considerably before we’re through. In fact, your single pizza shop handler might now look a lot more like its own, complete program.

At some point or another, you probably would have begun to wilt and see the wisdom of encapsulating the entire mess into its own code object, and you might even recognize now that (in some cases, at least) a program is effectively nothing more nor less than a collection of object modules that communicate with some master control element, almost like a large company with department managers reporting to the CEO­little programs, in other words, operating inside a big metaprogram.

The one downside of OOP from this point of view is that someone has to write the code objects, and if that someone is you, then yes, by golly, you do have to worry about what goes on inside them after all.