(Page 3 of 3 )A walking tour of JavaBeans What JavaBeans is, how it works, and why you want to use it

原创 2004年07月09日 14:26:00

A walking tour of JavaBeans

What JavaBeans is, how it works, and why you want to use it

Page 3 of 3


Event handling
All of this interaction between Beans presupposes some way for them to communicate. JDK 1.1 defines a new event model that classes (not just Beans!) use to communicate. In fact, this new event model has found its way into one of Java's most widely-used packages: java.awt!

In the new event model, a class registers interest in the activities of another class by way of a listener interface. In effect, the target object (the interested party) tells the source object (the object of interest), "Let me know whenever so-and-so happens." When the so-and-so occurs, the source object "fires" an event at the target by invoking the target's event handler with a subclass of EventObject as the argument.

Events can be used to implement bound and constrained properties. In the PieChart and SpreadSheet example above, the PieChart "registers" interest in any change to the SpreadSheet's (let's say) DataList property. When the SpreadSheet is going to change its DataList property, it passes a DataListChangedEvent (subclassed from EventObject), indicating what changed, to every interested listener's event handler method. The target (PieChart) then examines the event, and takes appropriate action.

The nuclear reactor example works similarly; but in that case, the target vetoes the change by throwing an exception. Thus the world is saved from widespread radioactive destruction.

The EventObject class can be extended to create user-defined events. Classes can now define and use new event types to send messages to one another. This means that Beans running inside the same container may communicate by passing messages around. This helps uncouple dependencies between objects, which we know is A Very Good Thing.

User-defined (and other) events are derived from the class java.util.EventObject.

The rather odd term introspection is Java-speak for the process of programmatically analyzing a class's public methods and members. This process is also sometimes called discovery. The new reflection mechanism in the Java core, which can dissect an object and return a description of its contents, makes introspection possible. (Although Java may be reflective, even introspective, omphaloskepsis is still not part of the core distribution.)

We've already run across one application of this capability. Above, we described an IDE that could construct a list of Bean properties to present to a developer. How can the IDE know what properties a Bean has? The IDE discovers a Bean's properties in one of two ways: by asking the Bean for a description of its properties, or by dissecting the Bean by introspecting it.

A typical IDE will start by asking a Bean for a BeanInfo object, which describes the Bean's properties, among other things. The IDE will then use the BeanInfo object to construct a property sheet. (This is assuming the Bean doesn't provide a customizer of its own.) If the Bean doesn't know how to return a BeanInfo object, the IDE then introspects the Bean, and scans the list of methods for names beginning with set and get. It assumes (by convention) that these methods are accessors for properties, and creates a new property sheet based on the accessor methods that exist and the types of the arguments those methods take. So, if the IDE finds methods like setColor(Color), Color getColor(), setSize(Size), and Size getSize(), then it will create a property sheet with the properties Color and Size, and appropriately-typed widgets for setting them.

This means that if a developer simply follows the conventions for naming accessor methods, an IDE can determine automatically how to create a customization property sheet for the component.

The reflection mechanism that performs introspection is in the new language core package java.lang.reflect.

Persistence and packaging
It's often useful to "freeze-dry" an object by converting its state into a blob of data to be packed away for later use -- or transmitted through a network for processing elsewhere. This process is called serialization and is a new feature of the Java core.

One of the simplest uses for serialization is to save the state of a customized Bean, so that a newly-constructed Bean's properties can be correctly set at run time.

Also, serialization is a mainstay of component technology, making possible distributed-processing schemes such as CORBA. If an object doesn't have the information locally that it needs to perform its task, it can send itself to a Request Broker, which serializes the object and sends it elsewhere for processing. On the remote end, the object is reconstituted and the originally-requested operation is performed. This is also a way to realize load balancing (for expensive tasks, that is: serialization and deserialization often aren't cheap).

Where do you keep a group of freeze-dried Beans that have been "pickled" in this way? Why, in a JAR, of course! The JavaBeans specification describes a JAR file as a structured ZIP file containing multiple serialized objects, documentation, images, class files, and so on, with a manifest that describes what's in the JAR. A JAR file, containing many compressed small files, can be downloaded all in one piece and decompressed on the client end, making applet downloading (for example) more efficient. (JAR is pretty obviously a play on the Unix tar file format.)

The java.io package provides object serialization. The JavaBeans Specification describes the format of JAR files.

Some wag once said that the nice thing about standards is that there are so many to choose from. Component technologies are no exception. There are many existing systems based on OLE (or its latest incarnation, ActiveX), OpenDoc, and LiveConnect. JavaBeans has been designed to (at least eventually) interoperate with these other component technologies.

It's not realistic to expect developers to abandon existing investments in other technologies and reimplement everything in Java. Since the release of Java 1.1, the first Beans/ActiveX "bridge" kits have become available, allowing developers to link Beans and ActiveX components seamlessly into the same application. The Java IDL interface, which will allow Java classes to operate with existing CORBA systems, is due out this year.

While the Beans/ActiveX bridge and Java IDL are not part of the standard JavaBeans distribution, they round out JavaBeans' capabilities as an industrial-strength, open technology for portable component software.

We've covered a lot of ground. In this article, you've learned what software components are and why they're valuable. You then learned about the various properties of JavaBeans, including properties, customization, events, introspection, persistence, packaging, and interoperation with legacy component systems.

In the next article in this series, we'll get you started using JavaBeans, and look at Bean properties in depth: how they work, and how to make your Beans customizable. As we go along, we'll discuss the new Java core features that make Beans possible. Future articles in this series will delve into the details of the topics we discussed this month. jw-dingbat.gif

Page 1 A walking tour of JavaBeans
Page 2 What JavaBeans is, and what it does
Page 3 Event handling


About the author
Mark Johnson has a BS in Computer and Electrical Engineering from Purdue University (1986). He has 15 years of experience programming in C and two years in C++, and is a fanatical devotee of the Design Pattern approach in object-oriented architecture, of software components in theory, and of JavaBeans in practice. Over the past several years, he worked for Kodak, Booz-Allen and Hamilton, and EDS in Mexico City, developing Oracle and Informix database applications for the Mexican Federal Electoral Institute and for Mexican Customs. He spent the last year working at NETdelivery, an Internet startup now in Boulder, CO. Mark is a dyed-in-the-wool Unix programmer, and sees Java as the missing link between the now ubiquitous desktop client systems and open, distributed, and scalable enterprise back-ends. He currently works as a designer and developer for Object Products in Fort Collins, CO.



下面是我今天写的一个Blog,转贴给大伙儿,希望论坛里的牛人多提批评意见。 最近几天有些网友在邮件里面问我关于学习的问题。有很多人觉得工作了几年,也学会了不少的类库、框架、甚至语言,但是感觉自己的能力...
  • zhaoyw2008
  • zhaoyw2008
  • 2013年07月05日 01:54
  • 2437


try { 代码3遍, 其意自见. 1. 不管懂不懂,照抄敲一遍。 2. 心中默念式敲一遍。 3. 完全不看自己敲一遍。(可以问人或自己google) ...
  • qq_34004585
  • qq_34004585
  • 2017年08月02日 12:00
  • 122


  • sushengmiyan
  • sushengmiyan
  • 2014年10月21日 15:34
  • 3192


一、什么是javabean 1、Javabeans就是符合某种特定规范Java类。使用Javabeans的好处是【解决代码的重复编写】,减少代码冗余,功能区分明确,提高代码的维护性。 2、设计原则...
  • u014038534
  • u014038534
  • 2016年01月18日 22:00
  • 2981

Stack_Queue 一个数组实现三个栈 @CareerCup

原文: Describe how you could use a single array to implement three stacks. 译文: 你如何只用一个数组实现三个栈...
  • hellobinfeng
  • hellobinfeng
  • 2014年03月01日 11:35
  • 1743

解析配置文件 redis.conf(七)

# Note on units: when memory size is needed, it is possible to specify # it in the usual form of 1k...
  • qq_29347295
  • qq_29347295
  • 2018年01月15日 09:01
  • 19

<Effective Java>理解"在构造过程中JavaBeans可能处于不一致的状态"

《Effective Java》的第二条:遇到多个构造器参数时考虑用构建器: 关于"在构造过程中JavaBeans可能处于不一致的状态"的理解....
  • digi3520
  • digi3520
  • 2017年03月29日 14:30
  • 293


  • lu_yongchao
  • lu_yongchao
  • 2017年02月28日 22:26
  • 1381

黑马程序员_Java高新技术3(框架,JavaBeans与内省(Introspector)) - 伊秋

1.Java框架(frame) /* 通俗例子: 我做房子(框架)卖给用户住,由用户自己安装门窗和空调(用户自定义类/用户自定义其它信息) 用户需要使用我的房子(框架),把符合框架中...
  • wangshfa
  • wangshfa
  • 2014年05月05日 16:19
  • 1893


2009-10-26powerdesigner12.5 入门教程   powerdesigner12.5 入门教程 下载powerdesigner12.5 进行破解和汉化: (1)powerdesig...
  • ttpage
  • ttpage
  • 2013年06月24日 13:53
  • 393
您举报文章:(Page 3 of 3 )A walking tour of JavaBeans What JavaBeans is, how it works, and why you want to use it