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).
But
how do you get an object to do useful work for you? There must be a way to make
a request of that object so 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. The idea of type being
equivalent to interface is fundamental in object-oriented programming.
A
simple example might be a representation of a light bulb:
Light lt = new Light();
lt.on();
The
name of the type/class is
Light,
and the requests that you can make of a
Light
object are to turn it on, turn it off, make it brighter or make it dimmer. You
create a “handle” for a
Light
simply
by declaring a name (
lt)
for that identifier, and you make an object of type
Light
with the
new
keyword, assigning it to the handle with the
=
sign. To send a message to the object, you state the handle name and connect it
to the message name with a period (dot). From the standpoint of the user of a
pre-defined class, that’s pretty much all there is to programming with
objects.
[3]
Some people make a distinction, stating that type determines the interface
while class is a particular implementation of that interface.
