What Is An Object?

In everyday life, an object is anything that is identifiably a single material item. An object can be a car, a house, a book, a document, or a paycheck. For the purposes here, you can extend that concept a bit and think of an object as anything that is a single item that you might want to represent in a program. This discussion therefore also includes 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.

Thinking about objects in this way not only enables you to write code that models the real world; it also enables you to break up a large program into smaller, more manageable units. The idea really comes from the concept of a black box that you might 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. Take, for example, a car radio. Most people don't know exactly how a car radio works; however, they do know what it does and how to operate it. Furthermore, they can take out the 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 the idea that there's a difference between what something does and how it works, and that two objects can do the same thing but work differently on the inside.

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

If you understand all that, you basically understand OOP, because OOP is about applying these same concepts to computer programming. If, in other areas of your life, you use objects that have a well-designed interface that you are familiar with, and you 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 and design each unit to perform a clearly specified role within the program. That's 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, because they can work on different objects in the code; all they need to know is what an object can do and how to interface with it. They don't have to worry about the details of how the underlying code works.