📄 chapter01.html
字号:
“the class of fishes and the class of birds.” The concept that all
objects, while being unique, are also part of a set of objects that have
characteristics and behaviors in common was directly used in the first
object-oriented language, Simula-67, with its fundamental keyword <B>class</B>
that introduces a new type into a program (thus <I>class</I> and <I>type</I> are
often used
synonymously</FONT><A NAME="fnB3" HREF="#fn3">[3]</A><FONT FACE="Georgia">).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Simula, as its name implies, was
created for developing simulations such as the classic “bank teller
problem.” In this, you have a bunch of tellers, customers, accounts,
transactions, etc. The members (elements) of each class share some commonality:
every account has a balance, every teller can accept a deposit, etc. At the same
time, each member has its own state; each account has a different balance, each
teller has a name. Thus the tellers, customers, accounts, transactions, etc. can
each be represented with a unique entity in the computer program. This entity is
the object, and each object belongs to a particular class that defines its
characteristics and behaviors.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">So, although what we really do in
object-oriented programming is create new data types, virtually all
object-oriented programming languages use the “class” keyword. When
you see the word “type” think “class” and vice
versa.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Once a type is established, you can
make as many objects of that type as you like, and then manipulate those objects
as the elements that exist in the problem you are trying to solve. Indeed, one
of the challenges of object-oriented programming is to create a one-to-one
mapping between the elements in the <I>problem space</I> (the place where the
problem actually exists) and the <I>solution space</I> (the place where
you’re modeling that problem, such as a computer).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">But how do you get an object to do
useful work for you? There must be a way to make a request of that object so it
will do something, such as complete a transaction, draw something on the screen
or turn on a switch. And each object can satisfy only certain requests. The
requests you can make of an object are defined by its <I>interface</I>, and the
type is what determines the interface. The idea of type being equivalent to
interface is fundamental in object-oriented programming.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">A simple example might be a
representation of a light bulb:</FONT><BR></P></DIV>
<DIV ALIGN="CENTER"><FONT FACE="Georgia"><IMG SRC="Tjava104.gif"></FONT><BR></P></DIV>
<BLOCKQUOTE><FONT SIZE = "+1"><PRE>Light lt = <font color=#0000ff>new</font> Light();
lt.on();</PRE></FONT></BLOCKQUOTE>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The name of the type/class is
<B>Light</B>, and the requests that you can make of a <B>Light</B> object are to
turn it on, turn it off, make it brighter or make it dimmer. You create a
“handle” for a <B>Light </B>simply by declaring a name (<B>lt</B>)
for that identifier, and you make an object of type <B>Light</B> with the
<B>new</B> keyword, assigning it to the handle with the <B>=</B> sign. To send a
message to the object, you state the handle name and connect it to the message
name with a period (dot). From the standpoint of the user of a pre-defined
class, that’s pretty much all there is to programming with
objects.</FONT><A NAME="_Toc375545190"></A><A NAME="_Toc408018387"></A><BR></P></DIV>
<A NAME="Heading20"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
The hidden implementation</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It is helpful to break up the
playing field into <I>class creators</I> (those who create new data types) and
<I>client
programmers</I></FONT><A NAME="fnB4" HREF="#fn4">[4]</A><FONT FACE="Georgia">
(the class consumers who use the data types in their applications). The goal of
the client programmer is to collect a toolbox full of classes to use for rapid
application development. The goal of the class creator is to build a class that
exposes only what’s necessary to the client programmer and keeps
everything else hidden. Why? If it’s hidden, the client programmer
can’t use it, which means that the class creator can change the hidden
portion at will without worrying about the impact to anyone
else.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The interface establishes
<I>what</I> requests you can make for a particular object. However, there must
be code somewhere to satisfy that request. This, along with the hidden data,
comprises the <I>implementation</I>. From a procedural programming standpoint,
it’s not that complicated. A type has a function associated with each
possible request, and when you make a particular request to an object, that
function is called. This process is often summarized by saying that you
“send a message” (make a request) to an object, and the object
figures out what to do with that message (it executes code).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">In any relationship it’s
important to have boundaries that are respected by all parties involved. When
you create a library, you establish a relationship with the client<I>
</I>programmer<A NAME="Index37"></A><A NAME="Index38"></A>, who is another
programmer, but one who is putting together an application or using your library
to build a bigger library.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">If all the members of a class are
available to everyone, then the client programmer can do anything with that
class and there’s no way to force any particular behaviors. Even though
you might really prefer that the client programmer not directly manipulate some
of the members of your class, without access control there’s no way to
prevent it. Everything’s naked to the world.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">There are two reasons for
controlling access <A NAME="Index39"></A><A NAME="Index40"></A>to members. The
first is to keep client programmers’ hands off portions they
shouldn’t touch – parts that are necessary for the internal
machinations of the data type but not part of the interface that users need to
solve their particular problems. This is actually a service to users because
they can easily see what’s important to them and what they can
ignore.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The second reason for access
control is to allow the library designer to change the internal workings of the
structure without worrying about how it will affect the client programmer. For
example, you might implement a particular class in a simple fashion to ease
development, and then later decide you need to rewrite it to make it run faster.
If the interface and implementation are clearly separated and protected, you can
accomplish this and require only a relink by the
user.<A NAME="Index41"></A><A NAME="Index42"></A><A NAME="Index43"></A></FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Java uses three explicit keywords
and one implied keyword to set the boundaries in a class: <B>public</B>,
<B>private</B>, <B>protected</B> and the implied “friendly,” which
is what you get if you don’t specify one of the other keywords. Their use
and meaning are remarkably straightforward. These <I>access specifiers</I>
<A NAME="Index44"></A><A NAME="Index45"></A><A NAME="Index46"></A>determine who
can use the definition that follows. <B>public</B> <A NAME="Index47"></A>means
the following definition is available to everyone. The <B>private</B>
<A NAME="Index48"></A>keyword, on the other hand, means that no one can access
that definition except you, the creator of the type, inside function members of
that type. <B>private</B> is a brick wall between you and the client programmer.
If someone tries to access a private member, they’ll get a compile-time
error. “Friendly” has to do with something called a
“package,” which is Java’s way of making libraries. If
something is “friendly” it’s available only within the
package. (Thus this access level is sometimes referred to as “package
access.”) <B>protected</B> acts just like <B>private</B>, with the
exception that an inheriting class has access to <B>protected</B> members, but
not <B>private</B> members. Inheritance will be covered
shortly.</FONT><A NAME="_Toc375545191"></A><A NAME="_Toc408018388"></A><BR></P></DIV>
<A NAME="Heading21"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Reusing <BR>the implementation</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Once a class has been created and
tested, it should (ideally) represent a useful unit of code. It turns out that
this reusability is not nearly so easy to achieve as many would hope; it takes
experience and insight to achieve a good design. But once you have such a
design, it begs to be reused. Code reuse is arguably the greatest leverage that
object-oriented programming languages provide.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The simplest way to reuse a class
is to just use an object of that class directly, but you can also place an
object of that class inside a new class. We call this “creating a member
object.” Your new class can be made up of any number and type of other
objects, whatever is necessary to achieve the functionality desired in your new
class. This concept is called <I>composition</I>, since you are composing a new
class from existing classes. Sometimes composition is referred to as a
“has-a” relationship, as in “a car has a
trunk.”</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Composition comes with a great deal
of flexibility. The <I>member objects</I> of your new class are usually private,
making them inaccessible to client programmers using the class. This allows you
to change those members without disturbing existing client code. You can also
change the member objects <I>at run time</I>, which provides great flexibility.
Inheritance, which is described next, does not have this flexibility since the
compiler must place restrictions on classes created with
inheritance.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Because inheritance is so important
in object-oriented programming it is often highly emphasized, and the new
programmer can get the idea that inheritance should be used everywhere. This can
result in awkward and overcomplicated designs. Instead, you should first look to
composition when creating new classes, since it is simpler and more flexible. If
you take this approach, your designs will stay cleaner. It will be reasonably
obvious when you need
inheritance.</FONT><A NAME="_Toc375545192"></A><A NAME="_Toc408018389"></A><BR></P></DIV>
<A NAME="Heading22"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Inheritance: <BR>reusing the interface</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">By itself, the concept of an object
is a convenient tool. It allows you to package data and functionality together
by <I>concept</I>, so you can represent an appropriate problem-space idea rather
than being forced to use the idioms of the underlying machine. These concepts
are expressed in the primary idea of the programming language as a data type
(using the <B>class</B> keyword).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It seems a pity, however, to go to
all the trouble to create a data type and then be forced to create a brand new
one that might have similar functionality. It’s nicer if we can take the
existing data type, clone it and make additions and modifications to the clone.
This is effectively what you get with <I>inheritance</I>, with the exception
that if the original class (called the <I>base</I> or <I>super</I> or
<I>parent</I> class) is changed, the modified “clone” (called the
<I>derived </I>or <I>inherited</I> or <I>sub</I> or <I>child</I><B> </B>class)
also reflects the appropriate changes. Inheritance is implemented in Java with
the <B>extends</B> keyword. You make a new class and you say that it
<B>extends</B> an existing class.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">When you inherit you create a new
type, and the new type contains not only all the members of the existing type
(although the <B>private</B> ones are hidden away and inaccessible), but more
importantly it duplicates the interface of the base class. That is, all the
messages you can send to objects of the base class you can also send to objects
of the derived class. Since we know the type of a class by the messages we can
send to it, this means that the derived class <I>is the same type as the base
class</I>. This type equivalence via inheritance is one of the fundamental
gateways in understanding the meaning of object-oriented
programming.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Since both the base class and
derived class have the same interface, there must be some implementation to go
along with that interface. That is, there must be a method to execute when an
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -