Chapter 1: Introduction to Objects { PA GE }
2. 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.
3. Each object has its own memory made up of other objects. Or, you make a new kind of object by making
a package containing existing objects. Thus, you can build up complexity in a program while hiding it
behind the simplicity of objects.
4. Every object has a type. Using the parlance, each object is an instance of a class, where “class” is
synonymous with “type.” The most important distinguishing characteristic of a class is “what messages can
you send to it?”
5. All objects of a particular type can receive the same messages. This is actually a very loaded statement,
as you will see later. Because an object of type circle is also an object of type shape, a circle is guaranteed to
receive shape messages. This means you can write code that talks to shapes and automatically handle
anything that fits the description of a shape. This substitutability is one of the most powerful concepts in
OOP.
Some language designers have decided that object-oriented programming itself is not adequate to easily
solve all programming problems, and advocate the combination of various approaches into multiparadigm
programming languages.2
An object has an interface
Aristotle was probably the first to begin a careful study of the concept of type. He was known to speak of
“the class of fishes and the class of birds.” The concept that all objects, while being unique, are also part of
a set of objects that have characteristics and behaviors in common was directly used in the first object-oriented
language, Simula-67, with its fundamental keyword class that introduces a new type into a
program (thus class and type are often used synonymously 3 ).
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, etc. The members
(elements) of each class share some commonality: every account has a balance, every teller can accept a
deposit, etc. At the same time, each member has its own state; each account has a different balance, each
teller has a name. Thus the tellers, customers, accounts, transactions, etc. can each be represented with a
unique entity in the computer program. This entity is the object, and each object belongs 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 all
object-oriented programming languages use the “class” keyword. When you see the word “type” think
“class” and vice versa.
Once a type is established, you can make as many objects of that type as you like, and then manipulate
those objects as the elements that exist in the problem you are trying to solve. Indeed, one of the challenges
of object-oriented programming is to create a one-to-one mapping between the elements in the problem
space (the place where the problem actually exists) and the solution space (the place where you’re
modeling that problem, such as a computer).
2 See Multiparadigm Programming in Leda by Timothy Budd (Addison-Wesley 1995).
3 Some people make a distinction, stating that type determines the interface while class is a particular implementation
of that interface.