C++ Interactive Course by Robert Lafore,
Page 1 of 701
CHAPTER 1A FIRST LOOL AT OOP AND C++
Welcome to the exciting world of object-oriented programming! In this first chapter, I’ll start by discussing whyobject-oriented programming (OOP) was invented and why it offers advantages to the programmer. I’ll also providea quick overview of the main features of object-oriented languages. You’ll learn about the two most fundamentalaspects of OOP, objects and classes. Then I’ll focus on a particular kind of object—hot dog stand—and show howreal hot dog stands on the street relate to hot dog stand objects in a program. You’ll see how to use C++ to describea 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 aboutold-fashioned procedural details. This one attacks objects and classes head-on. If you think of OOP as a fierce fire-breathing dragon, then you’re going to walk right up to it, look it squarely in the eye, and tell it you want answers,now!
Session 1: Why Do We Need OOP?
In this session, I’ll discuss, in a general way, how object-oriented programming arrived on the scene. OOP wasdeveloped because limitations were discovered in earlier approaches to programming. To appreciate what OOPdoes, you need to understand what these limitations are and how they arose from traditional programminglanguages.
Pascal, C, BASIC, Fortran, and similar traditional programming languages are
languages. That is, eachstatement in the language tells the computer to
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 a
) is needed. The programmer createsthe 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 aprogram of more than a few hundred statements unless it is broken down into smaller units. For this reason, the
was adopted as a way to make programs more comprehensible to their human creators. (The term functionis used in C++ and C. In other languages, the same concept may be called a
, or a
.) A program is divided into functions and—ideally, at least—each function has a clearly defined purposeand 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 alarger entity called a
, 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
, the somewhatloosely 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 signsof strain. You may have heard about, or been involved in, horror stories of program development. The project is toocomplex, the schedule slips, more programmers are added, complexity increases, costs skyrocket, the schedule slipsfurther, and disaster ensues (see
The Mythical Man-Month
, by Frederick P. Brooks, Jr., Addison-Wesley, 1982, for avivid description of this scenario).Analyzing the reasons for these failures reveals weaknesses in the procedural paradigm itself. No matter how wellthe 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.