📄 tij0148.html
字号:
<html><body>
<table width="100%"><tr>
<td>
<a href="http://www.bruceeckel.com/javabook.html">Bruce Eckel's Thinking in Java</a>
</td>
<td align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0147.html">Prev</a> | <a href="tij0149.html">Next</a>
</td>
</tr></table>
<hr>
<H2 ALIGN=LEFT>
The
new AWT
</H2>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">In
<A NAME="Index1810"></A>Java
1.1 a dramatic change has been accomplished in the creation of the new AWT.
Most of this change revolves around the <A NAME="Index1811"></A><A NAME="Index1812"></A>new
event model used in Java 1.1: as bad, awkward, and non-object-oriented as the
old event model was, the new event model is possibly the most elegant I have
seen. It’s difficult to understand how such a bad design (the old AWT)
and such a good one (the new event model) could come out of the same group.
This new way of thinking about events seems to drop so easily into your mind
that the issue no longer becomes an impediment; instead, it’s a tool that
helps you design the system. It’s also essential for Java Beans,
described later in the chapter.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Instead
of the non-object-oriented cascaded
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>if</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
statements in the old AWT, the new approach designates objects as
“sources” and “listeners” of events. As you will see,
the use of inner classes is integral to the object-oriented nature of the new
event model. In addition, events are now represented in a class hierarchy
instead of a single class, and you can create your own event types.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">You’ll
also find, if you’ve programmed with the old AWT, that Java 1.1 has made
a number of what might seem like gratuitous name changes. For example,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>setSize( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
replaces
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>resize( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
This will make sense when you learn about Java Beans, because Beans use a
particular naming convention. The names had to be modified to make the standard
AWT components into Beans.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Java
1.1 continues to support the old AWT to ensure backward compatibility with
existing programs. Without fully admitting disaster, the online documents for
Java 1.1 list all the problems involved with programming the old AWT and
describe how those problems are addressed in the new AWT.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Clipboard
operations are supported in 1.1, although drag-and-drop “will be
supported in a future release.” You can access the desktop color scheme
so your Java program can fit in with the rest of the desktop. Pop-up menus are
available, and there are some improvements for graphics and images. Mouseless
operation is supported. There is a simple API for printing and simplified
support for scrolling.
</FONT><a name="_Toc408018706"></a><P></DIV>
<A NAME="Heading424"></A><H3 ALIGN=LEFT>
The
new event model
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">In
the new event model a component can initiate (“fire”) an event.
Each type of event is represented by a distinct class. When an event is fired,
it is received by one or more “listeners,” which act on that event.
Thus, the source of an event and the place where the event is handled can be
separate.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Each
<A NAME="Index1813"></A><A NAME="Index1814"></A>event
listener is an object of a class that implements a particular type of listener
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>interface</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
So as a programmer, all you do is create a listener object and register it with
the component that’s firing the event. This registration is performed by
calling a
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>addXXXListener( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
method in the event-firing component, in which
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>XXX</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
represents the type of event listened for. You can easily know what types of
events can be handled by noticing the names of the <A NAME="Index1815"></A><A NAME="Index1816"></A>addListener
methods, and if you try to listen for the wrong events you’ll find out
your mistake at compile time. Java Beans also uses the names of the addListener
methods to determine what a Bean can do.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">All
of your event logic, then, will go inside a listener class. When you create a
listener class, the sole restriction is that it must implement the appropriate
interface. You can create a global listener class, but this is a situation in
which <A NAME="Index1817"></A><A NAME="Index1818"></A><A NAME="Index1819"></A>inner
classes tend to be quite useful, not only because they provide a logical
grouping of your listener classes inside the UI or business logic classes they
are serving, but because (as you shall see later) the fact that an inner class
object keeps a handle to its parent object provides a nice way to call across
class and subsystem boundaries.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">A
simple example will make this clear. Consider the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>Button2.java</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
example from earlier in this chapter.
</FONT><P></DIV>
<font color="#990000"><PRE><font color="#009900">//: Button2New.java</font>
<font color="#009900">// Capturing button presses</font>
<font color="#0000ff">import</font> java.awt.*;
<font color="#0000ff">import</font> java.awt.event.*; <font color="#009900">// Must add this</font>
<font color="#0000ff">import</font> java.applet.*;
<font color="#0000ff">public</font> <font color="#0000ff">class</font> Button2New <font color="#0000ff">extends</font> Applet {
Button
b1 = <font color="#0000ff">new</font> Button("Button 1"),
b2 = <font color="#0000ff">new</font> Button("Button 2");
<font color="#0000ff">public</font> <font color="#0000ff">void</font> init() {
b1.addActionListener(<font color="#0000ff">new</font> B1());
b2.addActionListener(<font color="#0000ff">new</font> B2());
add(b1);
add(b2);
}
<font color="#0000ff">class</font> B1 <font color="#0000ff">implements</font> ActionListener {
<font color="#0000ff">public</font> <font color="#0000ff">void</font> actionPerformed(ActionEvent e) {
getAppletContext().showStatus("Button 1");
}
}
<font color="#0000ff">class</font> B2 <font color="#0000ff">implements</font> ActionListener {
<font color="#0000ff">public</font> <font color="#0000ff">void</font> actionPerformed(ActionEvent e) {
getAppletContext().showStatus("Button 2");
}
}
<font color="#009900">/* The old way:
public boolean action(Event evt, Object arg) {
if(evt.target.equals(b1))
getAppletContext().showStatus("Button 1");
else if(evt.target.equals(b2))
getAppletContext().showStatus("Button 2");
// Let the base class handle it:
else
return super.action(evt, arg);
return true; // We've handled it here
}
*/</font>
} <font color="#009900">///:~ </PRE></font></font><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">So
you can compare the two approaches, the old code is left in as a comment. In
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>init( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
the only change is the addition of the two lines:
</FONT><P></DIV>
<font color="#990000"><PRE>b1.addActionListener(<font color="#0000ff">new</font> B1());
b2.addActionListener(<font color="#0000ff">new</font> B2()); </PRE></font><DIV ALIGN=LEFT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>addActionListener( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
tells a button which object to activate when the button is pressed. The classes
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>B1</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>B2</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
are inner classes that implement the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>interface
ActionListener
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
This interface contains a single method
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>actionPerformed( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
(meaning “This is the action that will be performed when the event is
fired”). Note that
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>actionPerformed( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
does not take a generic event, but rather a specific type of event,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>ActionEvent</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
So you don’t need to bother testing and downcasting the argument if you
want to extract specific
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>ActionEvent</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
information.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">One
of the nicest things about
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>actionPerformed( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
is how simple it is. It’s just a method that gets called. Compare it to
the old
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>action( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
method, in which you must figure out what happened and act appropriately, and
also worry about calling the base class version of
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>action( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and return a value to indicate whether it’s been handled. With the new
event model you know that all the event-detection logic is taken care of so you
don’t have to figure that out; you just say what happens and you’re
done. If you’re don’t already prefer this approach over the old
one, you will soon.
</FONT><a name="_Toc408018707"></a><P></DIV>
<A NAME="Heading425"></A><H3 ALIGN=LEFT>
Event
and listener types
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">All
the AWT components have been changed to include
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>addXXXListener( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>removeXXXListener( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
methods so that the appropriate types of listeners can be added and removed
from each component. You’ll notice that the “
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>XXX</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">”
in each case also represents the argument for the method, for example,
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>addFooListener(FooListener
fl)
</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
The following table includes the associated events, listeners, methods, and the
components that support those particular events by providing the
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>addXXXListener( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
and
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><B>removeXXXListener( )</B></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -