Object-Oriented Programming in C++, 3rd Edition

[anbinhtrong]

Author(s) : Robert Lafore
Publisher : Waite Group
Year : Dec 1998
ISBN 10 : 157169160X
ISBN 13 : 9781571691606
Language : English
Pages : 850
File type : CHM
Size (for download) : 3.2 MB

Why is everyone so excited about OOP? The chief problem with computer programs is complexity. Large programs are probably the most complicated entities ever created by humans. Because of this complexity, programs are prone to error, and software errors can be expensive and even life threatening (in air-traffic control, for example). Object-Oriented Programming offers a new and powerful way to cope with this complexity. Its goal is clearer, more reliable, more easily maintained programs.

Of the Object-Oriented Programming languages, C++ is by far the most widely used. (Java, a recent addition to the field of OO languages, lacks certain features, such as pointers, that make it less powerful and versatile than C++.)

This book teaches Object-Oriented Programming with the C++ programming language, using either Microsoft or Borland compilers. It is suitable for professional programmers, students, and kitchen-table enthusiasts.

You can use this book even if you have no previous programming experience. However, such experience, in BASIC or Pascal, for example, certainly won’t hurt.

You do not need to know the C language to use this book. Many books on C++ assume that you already know C, but this one does not. It teaches C++ from the ground up. If you do know C, it won’t hurt, but you may be surprised at how little overlap there is between C and C++.

You should be familiar with the basic operations of Microsoft Windows, such as starting applications and copying files.


TABLE OF CONTENT:
Chapter 01 — The big picture
Chapter 02 — C++ programming basics
Chapter 03 — Loops and decisions
Chapter 04 — Structures
Chapter 05 — Functions
Chapter 06 — Objects and classes
Chapter 07 — Arrays and strings
Chapter 08 — Operator overloading
Chapter 09 — Inharitance
Chapter 10 — Pointers
Chapter 11 — Virtual functions
Chapter 12 — Streams and files
Chapter 13 — Multifile programs
Chapter 14 — Templates and exceptions
Chapter 15 — The standard template library
Chapter 16 — Object-oriented design

[anbinhtrong]

Cuốn này viết khá căn bản, nó dạy ta biết lập trình OOP như thế nào?

[anbinhtrong]

CHAPTER 1

THE BIG PICTURE

You will learn about the following in this chapter:
• Procedural versus object-oriented languages • Brief introduction to inheritance
• Features of object-oriented languages • C++ and C
• Brief introduction to classes and objects

This book teaches you how to program in C++, a computer language that supports Object-Oriented Programming (OOP). Why do we need OOP? What does it do that traditional languages like C, Pascal, and BASIC don’t? What are the principles behind OOP? Two key concepts in OOP are objects and classes. What do these terms mean? What is the relationship between C++ and the older C language?

This chapter explores these questions and provides an overview of the features to be discussed in the balance of the book. What we say here will necessarily be rather general (although mercifully brief). If you find the discussion somewhat abstract, don’t worry. The concepts we mention here will come into focus as we demonstrate them in detail in subsequent chapters.

Why Do We Need Object-Oriented Programming?
Object-Oriented Programming was developed because limitations were discovered in earlier approaches to programming. To appreciate what OOP does, we need to understand what these limitations are and how they arose from traditional programming languages.

Procedural Languages
C, Pascal, FORTRAN, and similar languages are procedural languages. That is, each statement in the language tells the computer to do 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 paradigm) 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 referred to as a subroutine, a subprogram, or a procedure.) A procedural program is divided into functions, and (ideally, at least) each 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 further extended by grouping a number of functions together into a larger entity called a module (which is often a file), but the principle is similar: a grouping of components that carries out specific tasks.

Dividing a program into functions and modules is one of the cornerstones of structured programming, the somewhat loosely defined discipline that influenced programming organization for several decades before the advent of Object-Oriented Programming.

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 process.)

Analyzing the reasons for these failures reveals that there are 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 these problems with procedural languages? There are two related problems. First, functions have unrestricted access to global data. Second, unrelated functions and data, the basis of the procedural paradigm, provide a poor model of the real world.

Let’s examine these problems in the context of an inventory program. One important global data item in such a program is the collection of items in the inventory. Various functions access this data to input a new item, display an item, modify an item, and so on.

Unrestricted Access

In a procedural program, one written in C for example, there are two kinds of data. Local data is hidden inside a function, and is used exclusively by the function. In the inventory program a display function might use local data to remember which item it was displaying. Local data is closely related to its function and is safe from modification by other functions.

However, when two or more functions must access the same data—and this is true of the most important data in a program—then the data must be made global, as our collection of inventory items is. Global data can be accessed by any function in the program. (We ignore the issue of grouping functions into modules, which doesn’t materially affect our argument.) The arrangement of local and global variables in a procedural program is shown in Figure 1.1.


Figure 1.1 Global and local variables.

In a large program, there are many functions and many global data items. The problem with the procedural paradigm is that this leads to an even larger number of potential connections between functions and data, as shown in Figure 1.2.

This large number of connections causes problems in several ways. First, it makes a program’s structure difficult to conceptualize. Second, it makes the program difficult to modify. A change made in a global data item may result in rewriting all the functions that access that item.

For example, in our inventory program, someone may decide that the product codes for the inventory items should be changed from five digits to 12 digits. This may necessitate a change from a short to a long data type.


Figure 1.2 The procedural paradigm.
Now all the functions that operate on the data must be modified to deal with a long instead of a short. It’s similar to what happens when your local supermarket moves the bread from aisle 4 to aisle 7. Everyone who patronizes the supermarket must then figure out where the bread has gone, and adjust their shopping habits accordingly.

[thanhcongmms]

thank thank thank

[Sponsored content]