📄 chapter01.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<!--
This document was converted from RTF source:
By rtftohtml 4.19
See http://www.sunpack.com/RTF
Filename:TIC2Vone.rtf
Application Directory:C:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:09/27/2001
Translation Time:05:25:23
Translation Platform:Win32
Number of Output files:22
This File:Chapter01.html
SplitDepth=1
SkipNavPanel=1
SkipLeadingToc=1
SkipTrailingToc=1
GenContents=1
GenFrames=1
GenIndex=1
-->
<HEAD lang="en"><META http-equiv="Content-Type" content="text/html">
<TITLE>1: Introduction to Objects</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF"><DIV ALIGN="CENTER">
<a href="http://www.MindView.net">
<img src="mindview-head.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README-HTML.txt">Viewing Hints</a> ]
[ <a href="http://www.mindview.net/CPPServices/SolutionGuide.html">Exercise Solutions</a> ]
[ <a href="http://www.mindview.net/ThinkingInCPP2e.html">Volume 2</a> ]
[ <a href="http://www.mindview.net/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/CPPServices/#PublicSeminars">Seminars</a> ]
[ <a href="http://www.mindview.net/CPPServices/#SeminarsOnCD">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/CPPServices/#ConsultingServices">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in C++, 2nd ed. Volume 1</FONT></H2></FONT>
<H3><FONT FACE="Verdana">©2000 by Bruce Eckel</FONT></H3></FONT>
<FONT FACE="Verdana" size = "-1">
[ <a href="Preface.html">Previous Chapter</a> ]
[ <a href="Contents.html">Table of Contents</a> ]
[ <a href="DocIndex.html">Index</a> ]
[ <a href="Chapter02.html">Next Chapter</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="_Toc472654681"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
1: Introduction to Objects</H1></FONT>
<A NAME="Heading20"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=4>The genesis of the computer
revolution was in a machine. The genesis of our programming languages thus tends
to look like that machine.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">But computers are not so much machines as
they are mind amplification tools (“bicycles for the mind,” as Steve
Jobs is fond of saying) and a different kind of expressive medium. As a result,
the tools are beginning to look less like machines and more like parts of our
minds, and also like other expressive mediums such as writing, painting,
sculpture, animation, and filmmaking. Object-oriented programming is part of
this movement toward using the computer as an expressive
medium.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This chapter will introduce you to the
<A NAME="Index58"></A><A NAME="Index59"></A><A NAME="Index60"></A><A NAME="Index61"></A>basic
concepts of object-oriented programming (OOP), including an overview of OOP
development methods. This chapter, and this <A NAME="Index62"></A>book, assume
that you have had experience in a procedural programming language, although not
necessarily C. If you think you need more preparation in programming and the
syntax of C before tackling this book, you should work through the
“Thinking in C: Foundations for C++ and Java” training CD ROM, bound
in with this book and also available at <I>www.BruceEckel.com</I>.
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This chapter is background and
supplementary material. Many people do not feel comfortable wading into
object-oriented programming without understanding the big picture first. Thus,
there are many concepts that are introduced here to give you a solid overview of
OOP. However, many other people don’t get the big picture concepts until
they’ve seen some of the mechanics first; these people may become bogged
down and lost without some code to get their hands on. If you’re part of
this latter group and are eager to get to the specifics of the language, feel
free to jump past this chapter – skipping it at this point will not
prevent you from writing programs or learning the language. However, you will
want to come back here eventually to fill in your knowledge so you can
understand why objects are important and how to design with
them.</FONT><A NAME="_Toc375545188"></A><A NAME="_Toc408018385"></A><A NAME="_Toc472654682"></A><BR></P></DIV>
<A NAME="Heading21"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
The progress of abstraction<A NAME="mark"></A></H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">All programming languages provide
abstractions. It can be argued that the complexity of the problems you’re
able to solve is directly related to the kind and quality of
<A NAME="Index63"></A>abstraction. By “kind” I mean, “What is
it that you are abstracting?” Assembly language is a small abstraction of
the underlying machine. Many so-called “imperative” languages that
followed (such as Fortran, BASIC, and C) were abstractions of assembly language.
These languages are big improvements over assembly language, but their primary
abstraction still requires you to think in terms of the structure of the
computer rather than the structure of the problem you are trying to solve. The
programmer must establish the association between the machine model (in the
“<A NAME="Index64"></A><A NAME="Index65"></A>solution space,” which
is the place where you’re modeling that problem, such as a computer) and
the model of the problem that is actually being solved (in the
“<A NAME="Index66"></A><A NAME="Index67"></A>problem space,” which
is the place where the problem exists). The effort required to perform this
mapping, and the fact that it is extrinsic to the programming language, produces
programs that are difficult to write and expensive to maintain, and as a side
effect created the entire “programming methods”
industry.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The alternative to modeling the machine
is to model the problem you’re trying to solve. Early languages such as
LISP and APL chose particular views of the world (“All problems are
ultimately lists” or “All problems are algorithmic”). PROLOG
casts all problems into chains of decisions. Languages have been created for
constraint-based programming and for programming exclusively by manipulating
graphical symbols. (The latter proved to be too restrictive.) Each of these
approaches is a good solution to the particular class of problem they’re
designed to solve, but when you step outside of that domain they become awkward.
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The object-oriented approach goes a step
farther by providing tools for the programmer to represent elements in the
problem space. This representation is general enough that the programmer is not
constrained to any particular type of problem. We refer to the elements in the
problem space and their representations in the solution space
as<A NAME="Index68"></A> “objects.” (Of course, you will also need
other objects that don’t have problem-space analogs.) The idea is that the
program is allowed to adapt itself to the lingo of the problem by adding new
types of objects, so when you read the code describing the solution,
you’re reading words that also express the problem. This is a more
flexible and powerful language abstraction than what we’ve had before.
Thus, OOP allows you to describe the problem in terms of the problem, rather
than in terms of the computer where the solution will run. There’s still a
connection back to the computer, though. Each object looks quite a bit like a
little computer; it has a state, and it has operations that you can ask it to
perform. However, this doesn’t seem like such a bad analogy to objects in
the real world; they all have characteristics and behaviors. </FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Some language designers have decided that
object-oriented programming by itself is not adequate to easily solve all
programming problems, and advocate the combination of various approaches into
<I>multiparadigm</I> programming
languages.</FONT><A NAME="fnB4" HREF="#fn4">[4]</A><A NAME="Index69"></A><A NAME="Index70"></A><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Alan Kay summarized five
<A NAME="Index71"></A>basic characteristics of <A NAME="Index72"></A>Smalltalk,
the first successful object-oriented language and one of the languages upon
which C++ is based. These characteristics represent a pure approach to
object-oriented
programming<A NAME="Index73"></A><A NAME="Index74"></A><A NAME="Index75"></A><A NAME="Index76"></A>:</FONT><BR></P></DIV>
<OL>
<LI><FONT FACE="Verdana"><B> Everything is an
object.</B></FONT><FONT FACE="Georgia"> Think of an object as a fancy variable;
it stores data, but you can “make requests” to that object, asking
it to perform operations on itself. In theory, you can take any conceptual
component in the problem you’re trying to solve (dogs, buildings,
services, etc.) and represent it as an object in your
program.</FONT><LI><FONT FACE="Verdana"><B> A program is a bunch of objects
telling each other what to do by sending
messages</B></FONT><FONT FACE="Georgia">. To make a request of an object, you
“send a message” to that object. More concretely, you can think of a
message as a request to call a function that belongs to a particular
object.</FONT><LI><FONT FACE="Verdana"><B> Each object has its own memory made
up of other objects</B></FONT><FONT FACE="Georgia">. Put another way, you create
a new kind of object by making a package containing existing objects. Thus, you
can build complexity in a program while hiding it behind the simplicity of
objects.</FONT><LI><FONT FACE="Verdana"><B> Every object has a
type</B></FONT><FONT FACE="Georgia">. Using the parlance, each object is an
<I>instance</I> of a <I>class</I>, in which “class” is synonymous
with “type.” The most important distinguishing characteristic of a
class is “What messages can you send to
it?”</FONT><LI><FONT FACE="Verdana"><B> All objects of a particular type
can receive the same messages</B></FONT><FONT FACE="Georgia">. This is actually
a loaded statement, as you will see later. Because an object of type
“circle” is also an object of type “shape,” a circle is
guaranteed to accept shape messages. This means you can write code that talks to
shapes and automatically handles anything that fits the description of a shape.
This <I>substitutability</I> is one of the most powerful concepts in
OOP.</FONT><A NAME="_Toc375545189"></A><A NAME="_Toc408018386"></A><A NAME="_Toc472654683"></A></OL><A NAME="Heading22"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
An object has an interface<BR><A NAME="Index77"></A><A NAME="Index78"></A></H2></FONT>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -