What is an Object?

 

Appendix A - Principles of Object-Oriented Programming
bySimon Robinsonet al.
Wrox Press 2002

  

In everyday life, an object is anything that is identifiably a single material item. It could be a car, a house, a book, a document, or a pay check. For our purposes, we're going to extend that a bit and think of an object as anything whatsoever that is a single item that you might want to represent in a program. We'll therefore also include living "objects", such as a person, an employee, or a customer, as well as more abstract "objects", such as a company, a database, or a country.

The reason for thinking about objects in this way is partly so that we'll be able to write code that models the real world, to the extent that it contains objects, and partly to provide a way of breaking up a large program into smaller, more manageable, units. The idea really comes from the concept of a black box that you may have encountered in school science.

The idea of a black box is that there are a lot of objects in life that you are able to use but of which you don't understand the mechanism. Look at your car radio, for example. Most people don't know exactly how a car radio works, but know what it does and are still able to use it. Not only that, but you can take out your radio, plug in a different one and it'll do basically the same thing, even though the internal workings of it might be completely different. Black boxes formalize this idea that there's a difference between what something does, which you usually know, and how it works (which you usually don't need to know) and that two objects can do the same thing, but work differently inside.

Replacing one object with another does have some subtle effects. Car radios might have different knobs and switches, but the basic function is unchanged. Another important point is that the basic user interface is unchanged; I plug one car stereo into the slot in much the same way as I would another.

If you understand all that, then you basically understand object-oriented programming, because OOP is about applying these same concepts to computer programming. If, in other areas of our lives, we use things that have a well-designed interface, whose function we know, and we know how to use them, but don't care how they work, why not do the same thing in your programs? In other words, break each program into lots of units, each designed to perform a clearly specified role within the program. That's basically what an object is.

If you start thinking about your programs this way, you gain quite a few advantages. You'll find it becomes easier to design the programs. The architecture of the programs becomes more intuitive and easier to understand, because it more closely reflects whatever it is that the program is abstracting from real life. It becomes easier for multiple developers to work together, since they can work on different objects in the code; they only need to know what each other's objects do, and how to interface with them. They don't have to worry about the details of how each other's code works.