📄 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:Tjava14.rtf
Application Directory:c:\TOOLS\RTF2HTML\
Subject:
Author:Bruce Eckel
Operator:Bruce Eckel
Document Comments:
Version Comments:
Comments:
Keywords:
Translation Date:02/04/2000
Translation Time:23:24:31
Translation Platform:Win32
Number of Output files:27
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/TIJ2/index.html">2nd Edition</a> ]
[ <a href="http://www.mindview.net/MailingList.html">Free Newsletter</a> ] <br>
[ <a href="http://www.mindview.net/Training.html">Seminars</a> ]
[ <a href="http://www.mindview.net/javaCD2.html">Seminars on CD ROM</a> ]
[ <a href="http://www.mindview.net/CPPServices/#ConsultingServices">Consulting</a> ]
</FONT>
<H2><FONT FACE="Verdana">
Thinking in Java, 1st edition</FONT></H2>
<H3><FONT FACE="Verdana">©1998 by Bruce Eckel</FONT></H3>
<FONT FACE="Verdana" size = "-1">
[ <a href="Introduction.html">Previous Chapter</a> ]
[ <a href="SimpleContents.html">Short TOC</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="_Toc375545187"></A><A NAME="_Toc407441445"></A><A NAME="_Toc408018384"></A><A NAME="Heading17"></A><FONT FACE = "Verdana"><H1 ALIGN="LEFT">
1: Introduction <BR>to objects</H1></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Verdana" SIZE=4>Why has object-oriented
programming had such a sweeping impact on the software development community?
</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index28"></A><A NAME="Index29"></A><FONT FACE="Georgia">Object-oriented
programming appeals at multiple levels. For managers, it promises faster and
cheaper development and maintenance. For analysts and designers, the modeling
process becomes simpler and produces a clear, manageable design. For
programmers, the elegance and clarity of the object model and the power of
object-oriented tools and libraries makes programming a much more pleasant task,
and programmers experience an increase in productivity. Everybody wins, it would
seem.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">If there’s a downside, it is
the expense of the learning curve. Thinking in objects is a dramatic departure
from thinking procedurally, and the process of
<A NAME="Index30"></A><I>designing</I> objects is much more challenging than
procedural design, especially if you’re trying to create reusable
objects.<I> </I>In the past, a novice practitioner of object-oriented
programming was faced with a choice between two daunting tasks:
</FONT><BR></P></DIV>
<OL>
<LI><FONT FACE="Georgia"> Choose a language such as
<A NAME="Index31"></A>Smalltalk in which you had to learn a large library before
becoming productive. </FONT><LI><FONT FACE="Georgia"> Choose
<A NAME="Index32"></A>C++ with virtually no libraries at
all,</FONT><A NAME="fnB1" HREF="#fn1">[1]</A><FONT FACE="Georgia"> and
struggle through the depths of the language in order to write your own libraries
of objects<I>.</I></FONT></OL><DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It
is, in fact, difficult to design objects well – for that matter,
it’s hard to design <I>anything</I> well. But the intent is that a
relatively few experts design the best objects for others to consume. Successful
OOP languages incorporate not just language syntax and a compiler, but an entire
development environment <I>including</I> a significant library of well-designed,
easy to use objects. Thus, the primary job of most programmers is to use
existing objects to solve their application problems. The goal of this chapter
is to show you what object-oriented programming is and how simple it can
be.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This chapter will introduce many of
the ideas of Java and object-oriented programming on a conceptual level, but
keep in mind that you’re not expected to be able to write full-fledged
Java programs after reading this chapter. All the detailed descriptions and
examples will follow throughout the course of this
book.</FONT><A NAME="_Toc375545188"></A><A NAME="_Toc408018385"></A><BR></P></DIV>
<A NAME="Heading18"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
The progress of abstraction</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 can solve
is directly related to the kind and quality of
<A NAME="Index33"></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
“solution space”) and the model of the problem that is actually
being solved (in the “problem space”). 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 takes
a step farther by providing tools for the programmer to represent elements in
the <A NAME="Index34"></A>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="Index35"></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 the terms of the solution. 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 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">Alan Kay summarized five basic
characteristics of <A NAME="Index36"></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:</FONT><BR></P></DIV>
<OL>
<LI><FONT FACE="Georgia" SIZE=2><B> Everything is an object.</B> Think of
an object as a fancy variable; it stores data, but you can also ask it to
perform operations on itself by making requests. 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="Georgia" SIZE=2><B> A program is a bunch of
objects telling each other what to do by sending messages</B>. 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="Georgia" SIZE=2><B> Each object
has its own memory made up of other objects</B>. Or, you make a new kind of
object by making a package containing existing objects. Thus, you can build up
complexity in a program while hiding it behind the simplicity of
objects.</FONT><LI><FONT FACE="Georgia" SIZE=2><B> Every object has a
type</B>. Using the parlance, each object is an <I>instance</I> of a
<I>class</I>, where “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="Georgia" SIZE=2><B> All objects of a
particular type can receive the same messages</B>. This is actually a very
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 receive shape messages.
This means you can write code that talks to shapes and automatically handle
anything that fits the description of a shape. This <I>substitutability</I> is
one of the most powerful concepts in
OOP.</FONT></OL><DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Some language
designers have decided that object-oriented programming 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><FONT FACE="Georgia">
</FONT><A NAME="_Toc375545189"></A><A NAME="_Toc408018386"></A><BR></P></DIV>
<A NAME="Heading19"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
An object has an interface</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Aristotle was probably the first to
begin a careful study of the concept of type. He was known to speak of
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -