?? chap01.htm
字號:
<!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:TIJ2.rtf
Application Directory:C:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:05/21/2001
Translation Time:10:39:02
Translation Platform:Win32
Number of Output files:23
This File:Chap01.htm
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.gif" alt="MindView Inc." BORDER = "0"></a>
<CENTER>
<FONT FACE="Verdana" size = "-1">
[ <a href="README.txt">Viewing Hints</a> ]
[ <a href="RevHist.htm">Revision History</a> ]
[ <a href="http://www.mindview.net/Books/TIJ/">Book Home Page</a> ]
[ <a href="http://www.mindview.net/Etc/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/Seminars">Seminars</a> ]
[ <a href="http://www.mindview.net/CDs">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/Services">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in Java, 2nd edition, Revision 12</FONT></H2>
<H3><FONT FACE="Verdana">©2000 by Bruce Eckel</FONT></H3>
<FONT FACE="Verdana" size = "-1">
[ <a href="Intro.htm">Previous Chapter</a> ]
[ <a href="SimpCont.htm">Short TOC</a> ]
[ <a href="Contents.htm">Table of Contents</a> ]
[ <a href="DocIdx.htm">Index</a> ]
[ <a href="Chap02.htm">Next Chapter</a> ]
</FONT>
</CENTER>
</P></DIV><A NAME="_Toc375545187"></A><A NAME="_Toc477690721"></A><A NAME="_Toc481064466"></A><A NAME="Heading21"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
1: Introduction <BR>to Objects</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia" SIZE=4><backtalk:display ID=TIJ3_CHAPTER1_I0>
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 forms of expression such as writing, painting,
sculpture, animation, and filmmaking. Object-oriented programming (OOP) is part
of this movement toward using the computer as an expressive
medium.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I0'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I1>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This chapter will introduce you to the
<A NAME="Index20"></A><A NAME="Index21"></A><A NAME="Index22"></A><A NAME="Index23"></A>basic
concepts of OOP, including an overview of development methods. This chapter, and
this <A NAME="Index24"></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 <I>Thinking in C: Foundations for C++ and
Java</I> training CD ROM, bound in with this book and also available at
<I>www.BruceEckel.com</I>.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I1'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I2>
</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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I2'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I3>
</FONT><A NAME="_Toc375545188"></A><A NAME="_Toc408018385"></A><A NAME="_Toc472654682"></A><A NAME="_Toc481064467"></A><BR></P></DIV>
<A NAME="Heading22"></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="Index25"></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="Index26"></A><A NAME="Index27"></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="Index28"></A><A NAME="Index29"></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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I3'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I4>
</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,”
respectively). 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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I4'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I5>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The object-oriented approach goes a step
further 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="Index30"></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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I5'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I6>
</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="fnB2" HREF="#fn2">[2]</A><A NAME="Index31"></A><A NAME="Index32"></A><FONT FACE="Georgia">
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I6'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I7>
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Alan Kay summarized five
<A NAME="Index33"></A>basic characteristics of <A NAME="Index34"></A>Smalltalk,
the first successful object-oriented language and one of the languages upon
which Java is based. These characteristics represent a pure approach to
object-oriented
programming<A NAME="Index35"></A><A NAME="Index36"></A><A NAME="Index37"></A><A NAME="Index38"></A>:
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I7'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I8>
</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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I8'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I9>
</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.
</backtalk:display>
[ <a href='http://www.mindview.net/backtalk/CommentServlet?ID=TIJ3_CHAPTER1_I9'
target="_blank">Add Comment</a> ]
<backtalk:display ID=TIJ3_CHAPTER1_I10>
</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.
</backtalk:display>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -