A walking tour of JavaBeans
What JavaBeans is, how it works, and why you want to use it
Printer-friendly version | 
Mail this to a friend
| Advertisement | |
|
What JavaBeans is, and what it does
JavaBeans is not a product, program, or development environment. It is both a core Java package (java.beans) that Beans may use to provided extended functionality, and a document (the JavaBeans Specification) that describes how to use the classes and interfaces in the java.beans package to implement "Beans functionality." The class specification is a part of the base release of Java 1.1, and so no additional software must be installed in order to use it. The addition of Beans required little change to the Java language per se, although several new and sorely-needed APIs were added to the core release to support Beans features. Reading the specification can be informative but soporific. Fortunately, it's optional if you already understand how and why to use the JavaBeans package. Perhaps you already understand Beans through reading an entertaining and enlightening series of articles on JavaBeans in JavaWorld, for example.
JavaBeans turns classes into software components by providing several new features. Some of these features are specific to Beans. Others, like serialization, can apply to any class, Bean or otherwise, but are crucial to the understanding and use of Beans.
Software components have properties, which are attributes of the object. Customization is the process of configuring a Bean for a particular task. The new event handling scheme in Java 1.1 was created in part to ease communication between Beans. Beans may be dissected by IDEs or by other classes through a process called introspection. Beans may be persisted (i.e., serialized) into byte streams for transmission or storage, and persisted Beans may be packaged into "JAR files" to ease downloading and access. Finally, Beans have been designed to interoperate easily with legacy component technologies such as ActiveX and LiveConnect, and participate in transactions with Object Request Broker systems such as CORBA.
Let's look at each one of these capabilities in a bit more depth.
Properties and customization
Properties, as noted above, are attributes of a Bean. Visual properties might include color or screen size. Other properties may have no visual representation: a BrowserHistory Bean, for example, might have a property specifying the maximum number of URLs to store. Beans expose setter and getter methods (called "accessor methods") for their properties, allowing other classes or IDEs to manipulate their state. The process of setting up a Bean's properties at design- or runtime is called customization.
The developer has a great deal of control over access and modification of Beans' properties. For a simple property, the developer writes a method called setProperty() and another called getProperty().
BarChart
For example, if you're using a Java-enabled browser, you will see to the left an applet which uses a small class called BarChart. The BarChart is the colored bar between the two buttons. BarChart lacks only one thing to become a Bean: it doesn't implement the interface java.io.Serializable (because most browsers don't yet handle Java 1.1, and so the example applet would fail.)
With the exception of being Serializable, BarChart is a simple Bean, with just a very few methods. It has void setPercent(int pct), which floods the bottom pct percent of the bar with red. The method int getPercent() returns the current percentage stored in the Bean (this is the Bean's state). The setPercent() method also calls repaint() if it changed the percentage, so that the visual representation of the object stays up-to-date.
The applet code calls setPercent(getPercent()+10) when the +10% button is clicked, causing the BarChart to increment its percentage (if it's < 100%). Percent is an example of a Bean property, with setter and getter methods named in accordance with the JavaBeans specification. As this series continues, we will transform this humble little BarChart into a useful software component that may be plugged into a variety of applications.
The value of an indexed property is an array. Indexed properties' accessor methods receive and return arrays of values instead of scalars. Accessor methods may throw checked exceptions to report error conditions.
Sometimes it's useful for an action to occur when a certain property of an object changes. Bound properties cause events to be sent to other objects when the property's value changes, possibly allowing the receiver to take some action. So, a SpreadSheet Bean might be configured to tell a PieChart Bean to redraw itself whenever the spreadsheet data changes.
Often, certain values for properties are illegal, based on the state of other Beans. A Bean can be set up to "listen" to these constrained properties of other Beans, and "veto" changes it doesn't like. For example, a nuclear reactor's ControlRodArray Bean might want to interfere with someone trying to change the state of a DrainReactorCorePump Bean to ON if the control rods are pulled out. (Don't try this at home. Probably no one should be using JavaBeans for such applications just yet.)
When a developer is connecting Beans together to create an application, the IDE can present a property sheet containing all the Beans' properties and their current values. (A property sheet is a dialog box used to set and/or view properties, like what you get by selecting Options… on a menu.) The developer sets the properties graphically, which the IDE translates into calls to the Beans' setter methods, changing the Beans' state. This customizes the Beans for the particular application.
Using lists of properties is not always the best way to handle customizing Beans. Some Beans have state that is too complex to be easily manipulated in this way. Other Beans would simply be cooler if there were a more intuitive way to set them up. Imagine the poor manager who simply wants to look at sales reports, and has to figure out what to type into the "Remote ODBC Data Source" text box in a property sheet. Wouldn't it be cooler if she could simply drag and drop a DataSource Bean's icon (customized with the label "Sales Data," of course) onto a DataConnection Bean, thereby configuring it automatically? A Beans developer can embed a property sheet into the Bean itself, and the IDE then uses this "customizer" to customize the Bean.
The relevant classes for manipulating properties and customization are in the java.beans package.
Page 1 A walking tour of JavaBeans
Page 2 What JavaBeans is, and what it does
Page 3 Event handling
扫一扫
3390
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
