The object-oriented approach goes a step further by providing tools for the programmer to represent
elements in the problem space. This representation is general enough that the programmer is not cons
trained to any particular type of problem. We refer to the elements in the problem space and their r
epresentations in the solution space as “objects.” (Of course, you will also need other objects that
don’t have problem-space analogs.) The idea is that the program is allowed to adapt itself to the l
ingo of the problem by adding new types of objects, so when you read the code describing the solutio
n, you’re reading words that also express the problem. This is a more flexible and powerful language
abstraction than what we’ve had before. Thus, OOP allows you to describe the problem in terms of th
e problem, rather than in terms of the computer where the solution will run. There’s still a connect
ion back to the computer, though. Each object looks quite a bit like a little computer; it has a sta
te, and it has operations that you can ask it to perform. However, this doesn’t seem like such a bad
analogy to objects in the real world—they all have characteristics and behaviors.
Some language designers have decided that object-oriented programming by itself is not adequate to e
asily solve all programming problems, and advocate the combination of various approaches into multip
aradigm programming languages.[2]
Alan Kay summarized five basic characteristics of Smalltalk, the first successful object-oriented la
nguage and one of the languages upon which Java is based. These characteristics represent a pure app
roach to object-oriented programming:
Everything is an object. Think of an object as a fancy variable; it stores data, but you can “make r
equests” to that object, asking it to perform operations on itself. In theory, you can take any conc
eptual component in the problem you’re trying to solve (dogs, buildings, services, etc.) and represe
nt it as an object in your program.
A program is a bunch of objects telling each other what to do by sending messages. To make a request
of an object, you “send a message” to that object. More concretely, you can think of a message as a
request to call a function that belongs to a particular object.
Each object has its own memory made up of other objects. Put another way, you create a new kind of o
bject by making a package containing existing objects. Thus, you can build complexity in a program w
hile hiding it behind the simplicity of objects.
Every object has a type. Using the parlance, each object is an instance of a class, in which “class”
is synonymous with “type.” The most important distinguishing characteristic of a class is “What mes
sages can you send to it?”
All objects of a particular type can receive the same messages. This is actually a loaded statement,
as you will see later. Because an object of type “circle” is also an object of type “shape,” a circ
le is guaranteed to accept shape messages. This means you can write code that talks to shapes and au
tomatically handle anything that fits the description of a shape. This substitutability is one of th
e most powerful concepts in OOP.
An object has an interface
Aristotle was probably the first to begin a careful study of the concept of type; he spoke of “the c
lass of fishes and the class of birds.” The idea that all objects, while being unique, are also part
of a class of objects that have characteristics and behaviors in common was used directly in the fi
rst object-oriented language, Simula-67, with its fundamental keyword class that introduces a new ty
pe into a program.
Simula, as its name implies, was created for developing simulations such as the classic “bank teller
problem.” In this, you have a bunch of tellers, customers, accounts, transactions, and units of mon
ey—a lot of “objects.” Objects that are identical except for their state during a program’s executio
n are grouped together into “classes of objects” and that’s where the keyword class came from. Creat
ing abstract data types (classes) is a fundamental concept in object-oriented programming. Abstract
data types work almost exactly like built-in types: You can create variables of a type (called objec
ts or instances in object-oriented parlance) and manipulate those variables (called sending messages
or requests; you send a message and the object figures out what to do with it). The members (elemen
ts) of each class share some commonality: every account has a balance, every teller can accept a dep
osit, etc. At the same time, each member has its own state, each account has a different balance, ea
ch teller has a name. Thus, the tellers, customers, accounts, transactions, etc., can each be repres
ented with a unique entity in the computer program. This entity is the object, and each object belon
gs to a particular class that defines its characteristics and behaviors.
So, although what we really do in object-oriented programming is create new data types, virtually al
l object-oriented programming languages use the “class” keyword. When you see the word “type” think
“class” and vice versa[3].
Since a class describes a set of objects that have identical characteristics (data elements) and beh
aviors (functionality), a class is really a data type because a floating point number, for example,
also has a set of characteristics and behaviors. The difference is that a programmer defines a class
to fit a problem rather than being forced to use an existing data type that was designed to represe
nt a unit of storage in a machine. You extend the programming language by adding new data types spec
ific to your needs. The programming system welcomes the new classes and gives them all the care and
type-checking that it gives to built-in types.
The object-oriented approach is not limited to building simulations. Whether or not you agree that a
ny program is a simulation of the system you’re designing, the use of OOP techniques can easily redu
ce a large set of problems to a simple solution.
Once a class is established, you can make as many objects of that class as you like, and then manipu
late those objects as if they are the elements that exist in the problem you are trying to solve. In
deed, one of the challenges of object-oriented programming is to create a one-to-one mapping between
the elements in the problem space and objects in the solution space.
But how do you get an object to do useful work for you? There must be a way to make a request of the
object so that it will do something, such as complete a transaction, draw something on the screen,
or turn on a switch. And each object can satisfy only certain requests. The requests you can make of
an object are defined by its interface, and the type is what determines the interface. A simple exa
mple might be a representation of a light bulb: