 | |
|
101, Part I Introduction | Page 2 | Page 3 | Page 4 What Distinguishes JavaBeans from Widgets? What Distinguishes JavaBeans from Java Classes? Definition: What is a Bean? If you use builder tools, such as Delphi or Visual Basic, you are already familiar with the notion of a bean. A JavaBean is a reusable software component that is written in Java programming language. It can be visually manipulated in builder tools. A JavaBean is often referred to simply as a Bean. Software components are self-contained, reusable software units. Using visual application builder tools, software components can be composed into applets, applications, servlets, and composite components. You perform this composition within a graphical user interface, and you can immediately see the results of your work. Reusable Software Components Reusable software components apply the concept of interchangeable parts to the field of software construction. Other industries have long profited from reusable components. For example, the builder tool above shows a calculator component that is built from 16 button components, a text field component, and a panel with buttons and a text display. Reusable software components can be simple, such as buttons, text fields, list boxes, scrollbars, and dialogs.
The above components are traditionally sold by third parties. More recently, vendors sell more complex software components, such as calendars and spreadsheets:
If you use visual component assembly tools, such as Visual Age, Delphi, Visual Basic, Mojo, or even PowerBuilder, you are familiar with the notion of software components. Visual Basic Extensions (VBXs) were the first widely used software components, followed by language-independent OLE Custom Controls (OCXs). UNIX programmers will be more familiar with widgets and toolkits. Reusable components add standardized interfaces and object introspection mechanisms to widgets, allowing builder tools to query components about their properties and behavior. Keep in mind, too, that software components need not be visible in a running application; they only need to be visible when the application is constructed.
For example, the builder tool above shows a calculator component that is built from 16 button
components, a text field component, and a panel with buttons and a text display are placed. Because
you are looking at the component in a builder tool, you can see five additional components
( A programmer can move, query, or visually hook together components while operating a builder tool. Often, such components do their work while the application is running, though they are invisible to the user. You can purchase custom JavaBean components from third party vendors. You can also purchase builder tools or application construction programs that support JavaBeans. Application construction tools let you build Java applications using the mouse as your primary input mechanism. You select components (from pallets, panels, or menus) and drop them into a form, or client window. You can change the behavior and look of these components by editing their properties, and you can link the actions of one component to another via events and event handlers. Components can be nested and arbitrarily complex. For example, a calculator built from components becomes, itself, a component to another application. Custom-built components are easily added to builder tool palettes. More complex components include barcharts, graphical diagram editors, and word processors. What Distinguishes JavaBeans from Widgets? JavaBeans define a design-time interface. This interface allows application designer tools, or builder tools, to query components to determine the kinds of properties the components define and the kinds of events they generate or to which they respond. In visual application builder environments, Beans are sometimes referred to as reusable software components or custom controls. Software components such as JavaBeans are packaged differently from standard Windows controls or Motif widgets. They are packaged with design-time information (properties and methods) that allow builder tools to determine their capabilities. In addition, end users, or third party suppliers, can build custom beans independently of the GUI platform or operating system. IS departments can distribute these third-party components to internal enterprise clients, or they can be sold as add-on components to anyone who uses builder tools to construct applications. What Distinguishes JavaBeans from Java Classes? Any Java class that adheres to certain conventions regarding property and event interface definitions can be a JavaBean. Beans are Java classes that can be manipulated in a visual builder tool and composed into applications. Introspection, the process by which a builder tool analyzes how a Bean works, differentiates Beans from typical Java classes. Because Beans are coded with predefined patterns for their method signatures and class definitions, tools that recognize these patterns can "look inside" a Bean and determine its properties and behavior. Introspection allows a Bean's state to be manipulated at design time—that is, at the time it is being assembled as a part within a larger application. For this to work, method signatures within Beans must follow a certain pattern so that introspection tools recognize how Beans can be manipulated, both at design time and at run time. In effect, Beans publish their attributes and behaviors through special method signature patterns that are recognized by beans-aware application construction tools. However, these construction tools are not required to build or test your beans. The pattern signatures are easily recognized by human readers, as well as builder tools. One of the first things you'll learn when building beans is how to recognize and construct methods that adhere to these patterns. Beans should not be used indiscriminately. Beans are best suited to software components intended to be visually manipulated within builder tools. Some functionality, such as the JDBC API, is still best provided through a programmatic or textual interface, rather than a visual manipulation interface. Introduction | Page 2 | Page 3 | Page 4 | ||||
| |
| ||||||||||||
Print-friendly Version
