Reusable software components are designed to apply the power and
benefit of reusable, interchangeable parts from other industries to
the field of software construction. Other industries have long
profited from reusable components. Reusable electronic components are
found on circuit boards. A typical part in your car can be replaced by
a component made from one of many different competing manufactuers.
Lucrative industries are built around parts construction and supply in
most competitive fields. The idea is that standard interfaces allow
for interchangeable, reusable components.
Reusable software components can be simple like familiar push buttons, text fields
list boxes, scrollbars, dialogs, for example
Button Beans
Slider Beans
Spinbutton Beans
These are the kinds of component sets, toolkits, or widget libraries
traditionally sold by third parties. Lately we've seen vendors
selling more complex software components like calendars,
and spreadsheets:
If you have used visual component
assembly tools such as Visual Age, Delphi, Visual Basic,
PARTS, Mojo, or even PowerBuilder, you are familiar with
the notion of software components.
Visual Basic Extensions (VBX's) were the
first widely used software components, followed
shortly 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. 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 upon which the buttons and a text display are placed. In
addition, you can see five invisible components. These specific
components hold values or strings used by the calculator for
intermediate calculations, operation codes, and display strings, as
well a boolean flag to determine when evaluation of a new expression
is started.
A programmer can move, query, or visually hook together components
such as numeric value holders, disk accessors, or network socket
components with a mouse while operating a builder tool. However, such
components would do their work invisibly while the application is
running.
With Beans, you can purchase custom components for Java from third
parties. You can also purchase builder tools or application
construction programs supporting Beans
Application construction tools let you
you to build Java
applications by visually selecting components from palettes, panels, or
menus, drop them into a form, or client
window, and hook up events to event handlers using the mouse as your
primary input mechanism.
Components can be nested and arbitrarily complex. For example, a
calculator built from components becomes, itself, a component.
Custom-built components are easily added to builder tool palettes.
More complex components include barcharts,
graphical diagram editors,
and word processors:
Beans, Widgets, Controls, and Components
Depending on your background, you may use different words
to describe GUI components for a given software platform.
If you come from a Windows background, you probably think
in terms of visual controls, possibly Visual Basic Extensions (VBXs)
or OLE Controls (OCXs) and now Active X Controls. If you're more
accustomed to environments like Motif or X Windows, you probably think
in terms of toolkits or widgets.
Beans are to widgets as VBXs or OCXs are to native Windows controls.
The main difference between Beans and native platform controls is
that they define a design-time interface, which allows application
designer tools, or builder tools to query
components and ask them what kinds of
properties they define, as well as what kinds
of events they can generate or respond to.
In visual application builder environments Beans are sometimes
referred to as reusable software components,
or custom controls.
The main thing that distinguishes software
components from standard Windows controls,
or Motif widgets is their packaging. Software
components or custom controls are packaged
with design-time information (properties and
methods) that allow builder tools
to determine their capabilities.
A second difference is that end users, or third party
suppliers can build custom beans independently of the
maker of the GUI platform or operating system. These
third-party components can then be distributed by
IS departments to internal enterprise clients, or
they can be sold as add-on components to anyone who
uses builder tools to construct applications.
Beans or Class Libraries
It's logical to wonder:
"What is the difference between a Java Bean and
an instance of a normal Java class?"
What differentiates Beans from typical Java classes is
introspection. Tools that recognize
predefined patterns in method signatures and class definitions can
"look inside" a Bean to determine its properties and behavior. A
Bean's state can be manipulated at the time it is being assembled as a
part within a larger application. The application assembly is referred
to as design time in contrast to
run time. In order for this scheme to work,
method signatures within Beans must follow a certain pattern in order
for introspection tools to recognize how Beans can be manipulated,
both at design time, and 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, you need not have one of these construction tools
in order to build or test your beans. The pattern
signatures are designed to be 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.
Not all useful software modules should be Beans.
Beans are best suited to software components intended
to be visually manipulated within builder tools.
Some functionality, however, is still best provided
through a programatic (textual) interface, rather than
a visual manipulation interface. For example, an SQL,
or JDBC API would probably be better suited to packaging
through a class library, rather than a Bean.
May Your Palette be Rich and Full
Still, Beans are tremendously useful, especially for
programmers who consider themselves domain experts
(financial analysts, scientists, linguists, bank loan
officiers, investment analysists, factory process
experts), rather than systems programmers.
Ideally, enterprise programmers and domain experts will have a rich pallet of
Beans from which to assemble Beans applications.
To Top