Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more ➡
Standard view
Full view
of .
Add note
Save to My Library
Sync to mobile
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
C++ Intertactive Course by Robert La Fore

C++ Intertactive Course by Robert La Fore

Ratings: (0)|Views: 819|Likes:
Published by api-26972476

More info:

Published by: api-26972476 on Oct 18, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See More
See less





C++ Interactive Course by Robert Lafore, Pdf by: Venkat Reddy
Page 1 of 701

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,

Session 1: Why Do We Need OOP?

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

Procedural Languages

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.

Division into Functions
When programs become larger, a single list of instructions becomes unwieldy. Few programmers can comprehend a
program of more than a few hundred statements unless it is broken down into smaller units. For this reason, the
function was adopted as a way to make programs more comprehensible to their human creators. (The term function
is used in C++ and C. In other languages, the same concept may be called asu b ro u tin e, asu bp ro g ra m, or a
procedure.) A program is divided into functions and\u2014ideally, at least\u2014each function has a clearly defined purpose

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.

Problems with Structured Programming

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.

C++ Interactive Course by Robert Lafore, Pdf by: Venkat Reddy
Page 2 of 701

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.

Figure 1-1 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.

C++ Interactive Course by Robert Lafore, Pdf by: Venkat Reddy
Page 3 of 701
Figure 1-2 The procedural paradigm
What is needed is a way to restrict access to the data, toh id e it from all but a few critical functions. This will protect
the data, simplify maintenance, and offer other benefits, as you\u2019ll see.
Relationship to the Real World

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.

New Data Types

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

Point and then add and subtract values of this type. Traditional programs are more complex to write and maintain.
The Object-Oriented Approach
The fundamental idea behind object-oriented languages is to combine into a single program entity bothd a ta andth e
functions that operate on that data. Such an entity is called an object.

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

hidden, so it is safe from accidental alteration. Data and its functions are said to be encapsulated into a single entity.
Encapsulationa nd data hiding are key terms in the description of object-oriented languages.

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.

Activity (5)

You've already reviewed this. Edit your review.
1 hundred reads
bhalesh liked this
Mark Richards liked this
jfscrbd liked this
sandydehrian liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->