There was a problem sending you an sms. Check your phone number or try again later.
We've sent a link to the Scribd app. If you didn't receive it, try again.
Welcome to the exciting world of object-oriented programming! In this first chapter, I\u2019ll start by discussing why
object-oriented programming (OOP) was invented and why it offers advantages to the programmer. I\u2019ll also provide
a quick overview of the main features of object-oriented languages. You\u2019ll learn about the two most fundamental
aspects of OOP, objects and classes. Then I\u2019ll focus on a particular kind of object\u2014hot dog stand\u2014and show how
real hot dog stands on the street relate to hot dog stand objects in a program. You\u2019ll see how to use C++ to describe
a class of hot dog stand objects and how to make these objects carry out tasks.
This approach goes to the very heart of OOP. Most books begin by skittering around the edges of C++, talking about
old-fashioned procedural details. This one attacks objects and classes head-on. If you think of OOP as a fierce fire-
breathing dragon, then you\u2019re going to walk right up to it, look it squarely in the eye, and tell it you want answers,
In this session, I\u2019ll discuss, in a general way, how object-oriented programming arrived on the scene. OOP was
developed because limitations were discovered in earlier approaches to programming. To appreciate what OOP
does, you need to understand what these limitations are and how they arose from traditional programming
Pascal, C, BASIC, Fortran, and similar traditional programming languages arep ro c e d u ra l languages. That is, each
statement in the language tells the computer tod o something: Get some input, add these numbers, divide by 6,
display that output. A program in a procedural language is a list of instructions.
For very small programs, no other organizing principle (often called ap a ra d ig m) is needed. The programmer creates
the list of instructions and the computer carries them out.
and a clearly defined interface to the other functions in the program.
The idea of breaking a program into functions can be extended by grouping a number of functions together into a
larger entity called amo d u le, but the principle is similar: a grouping of instructions that carry out specific tasks.
Dividing a program into functions and modules is one of the cornerstones of structured programming, the somewhat
loosely defined discipline that has influenced programming design for several decades.
As programs grow ever larger and more complex, even the structured programming approach begins to show signs
of strain. You may have heard about, or been involved in, horror stories of program development. The project is too
complex, the schedule slips, more programmers are added, complexity increases, costs skyrocket, the schedule slips
further, and disaster ensues (see The Mythical Man-Month, by Frederick P. Brooks, Jr., Addison-Wesley, 1982, for a
vivid description of this scenario).
Analyzing the reasons for these failures reveals weaknesses in the procedural paradigm itself. No matter how well
the structured programming approach is implemented, large programs become excessively complex.
What are the reasons for this failure of procedural languages? One of the most crucial is the role played by data.
In a procedural language, the emphasis is on doing things\u2014read the keyboard, invert the vector, check for errors,
and so on. The subdivision of a program into functions continues this emphasis. Functions do things, just as single
program statements do. What they do may be more complex or abstract, but the emphasis is still on the action.
What happens to the data in this paradigm? Data is, after all, the reason for a program\u2019s existence. The important
part of an inventory program isn\u2019t a function that displays the data or a function that checks for correct input; it\u2019s the
inventory data itself. Yet data is given second-class status in the organization of procedural languages.
For example, in an inventory program, the data that makes up the inventory is probably read from a disk file into
memory, where it is treated as a global variable. Byg lo b a l, I mean that the variables that constitute the data are
declared outside of any function so they are accessible to all functions. These functions perform various operations
on the data. They read it, analyze it, update it, rearrange it, display it, write it back to the disk, and so on.
I should note that most languages, such as Pascal and C, also supportlo ca l variables, which are hidden within a
single function. But local variables are not useful for important data that must be accessed by many different
functions. Figure 1-1 shows the relationship between global and local variables.
Suppose a new programmer is hired to write a function to analyze this inventory data in a certain way. Unfamiliar
with the subtleties of the program, the programmer creates a function that accidentally corrupts the data. This is easy
to do, because every function has complete access to the data. It\u2019s like leaving your personal papers in the lobby of
your apartment building: Anyone can change or destroy them. In the same way, global data can be corrupted by
functions that have no business changing it.
Another problem is that, because many functions access the same data, the way the data is stored becomes critical.
The arrangement of the data can\u2019t be changed without modifying all the functions that access it. If you add new data
items, for example, you\u2019ll need to modify all the functions that access the data so that they can also access these new
items. It will be hard to find all such functions and even harder to modify all of them correctly. It\u2019s similar to what
happens when your local supermarket moves the bread from aisle 4 to aisle 12. Everyone who patronizes the
supermarket must figure out where the bread has gone and adjust their shopping habits accordingly. The relationship
of functions and data in procedural programs is shown in Figure 1-2.
Procedural programs are often difficult to design. The problem is that their chief components\u2014functions and data
structures\u2014don\u2019t model the real world very well. For example, suppose you are writing code to create the elements
of a graphics user interface: menus, windows, and so on. Quick now, what functions will you need? What data
structures? The answers are not obvious, to say the least. It would be better if windows and menus corresponded
more closely to actual program elements.
There are other problems with traditional languages. One is the difficulty of creating new data types. Computer
languages typically have several built-in data types: integers, floating-point numbers, characters, and so on. What if
you want to invent your own data type? Perhaps you want to work with complex numbers, or two-dimensional
coordinates, or dates\u2014quantities the built-in data types don\u2019t handle easily. Being able to create your own types is
calledexten sib ility because you can extend the capabilities of the language. Traditional languages are not usually
extensible. Without unnatural convolutions, you can\u2019t bundle both x and y coordinates into a single variable called
An object\u2019s functions, called member functions in C++ (because they belong to a particular class of objects),
typically provide the only way to access its data. If you want to read a data item in an object, you call a member
function in the object. It will read the item and return the value to you. You can\u2019t access the data directly. The data is
If you want to modify the data in an object, you know exactly what functions interact with it: the member functions
in the object. No other functions can access the data. This simplifies writing, debugging, and maintaining the
A C++ program typically consists of a number of objects that communicate with each other by calling one another\u2019s
member functions. Figure 1-3 shows the organization of a C++ program.
Now bringing you back...
Does that email address look wrong? Try again with a different email.