1 - Component-Based Programming

By the end of this chapter, the reader will be able to:

In this chapter we take our first hesitant steps towards learning about component-based solutions. The vast, dark abyss of the unknown spreads out before us, ready to consume our souls and leave us sad and forlorn, begging for mercy. But fear not, you have in your hands a lantern of knowledge! A beacon of hope, that will light your way through the cruel and unforgiving depths of bewilderment!

In this chapter we're going to look at what we mean by component, and why we need them in the first place. We're also going to look at one of the more accessible component frameworks - that of the JavaBean. As this is our first foray into this uncharted territory, it will of a necessity be rather brief. Later quests for knowledge will allow us to map the terrain far more completely. Tally ho!

Components are specialisations of objects. Actually, that's not true. Components can be specialisations of objects. However, they don't have to be. Object orientation as a programming paradigm has made the development of components much simpler than it has been in the past.

In its purest sense, a component is an independent package of functionality. The abstract idea is that a software component should simulate the traits of a hardware component - when you want to screw in a light bulb, you don't need to spend an hour wiring up the switch. Instead, you just plug it in and it works. When the light bulb blows, you can take that one out and swap in another one with minimal effort, and it's all up and running again. If you need a brighter light, you swap in a more powerful bulb.

Software components are designed in a similar way - they are meant for easy deployment in a host system, and that deployment should be implemented in such a way as to ensure the component runs largely autonomously.

Software components are designed so that they can 'slot in' to a program and work with minimal 'stitching'. The primary difference between a component and an object lies in the pragmatic design model used.

Objects are designed to model real world interactions, and in a given problem domain there will usually be an object for each noun. They are usually tailored towards individual developer needs, either by specialisation or extension. Usually, they are either too generalised (and so a developer must add in custom functionality) or too specialised (and so a developer must refine the object for his own use). Good object oriented design minimises this problem, but does not eliminate it.

Components on the other hand are designed as a holistic unit of functionality. The idea behind component-based programming is that software should be built by 'gluing' pre-built software components together. Component design often runs counter to object design - we will have cause to return to this subject later in the book.

Components, like classes, conform to an interface that describes the data that goes into them and the data that comes out. We'll talk about this again a little later in this chapter.

Okay, I accept that isn't the most accessible of definitions. Perhaps the easiest way to think of a component is as a finished product... the kind of thing you'd be able to pass off to suckers in exchange for money. Usually, objects and classes are partially engineered solutions to a problem. They may have all the functionality of a component, but they lack the 'interchangeability'.

When making use of an object that someone else has written, I usually have to change my program to conform to their design assumptions. For example, if someone writes an object that will parse certain kinds of information from a string, I need to ensure my string is in the correct format. If someone writes an object that displays an animation at particular co-ordinates, I need to make sure that my co-ordinates are in a suitable format.

With components, this isn't necessary - at their best, components are 'plug and play'. You may still need to write some code to go with them, but this code is to meet your specialised requirements. You don't need to restructure your code to get the component to work - it'll work by itself.

The simplest example of a component is a GUI widget, such as you'd find in a builder environment like Visual Basic. Each of the GUI widgets is plug and play - you select a button, drag it onto your form, and then you have a working button! It may not do anything (because you have specialised requirements), but it's there and it works and it requires no code from you to make it work.

Components do not have to be this simple - they can be as complex as fully featured programs in themselves. For example, of one of the components available in Visual Basic is an HTML component. Drag and drop it onto your form, and you have a fully featured web-browser.

It is appropriate that Visual Basic provides the most succinct articulation of the component idea - Visual Basic was the language that popularised the idea of components in the first place. Their basic theory was proposed way back in '68, but it took Microsoft and Visual Basic to provide a workable implementation.

Components have of course evolved quite a bit since then, and now encapsulate a whole range of protocols for local and distributed services. We'll investigate these as the module progresses.

From what we've discussed so far, it's not really easy to see what the difference is between a class and a component. Both provide standard functionality and hide the implementation. Both conform to a set interface - so where's the difference?

The real difference comes in the form of a software component specification. This is a definition, enforced in code (usually) that determines what a class or collection of classes must implement in order to be considered a component. Almost all software components are classes - the idea of a component itself is largely a specialisation of a class (although it doesn't have to be).

In this chapter we're going to look at one particular example of a software component specification - that of the JavaBean.

JavaBeans are the primary component model for the Java programming language. They are simple in form and syntax, and easy to implement without significant expenditure of time and effort.

Well...

That's true of standard JavaBeans. The phrase 'JavaBean' is not particularly helpful since there are two families of JavaBeans. Standard JavaBeans are a specialisation of the standard Java object. Enterprise JavaBeans are something else entirely, and far beyond the scope of this brief introduction. So we'll just ignore them!

It should be noted at this point that there are many software development tools that automate the creation of JavaBeans and other such components. We're not going to look at them, because they obscure genuine understanding. It is only by getting dirty with the internals of how components work that we can truly make use of their potential.

JavaBeans are just standard Java classes, with a little extra tacked on. The JavaBean Software Component Specification defines what this 'little extra' actually involves. Let's start off with a very simple class and build that into a bean. It won't be a useful bean, but a bean it will be.

Let's start off with a class that contains a JButton. When that button is pressed, it flashes up the messages 'Beenz Beenz The Musical Froot':

import javax.swing.*; import java.awt.*; import java.awt.event.*; public class MyFirstBean extends JPanel implements ActionListener { JButton myButton; public MyFirstBean() { Container c = getContentPane(); myButton = new JButton ("Press Me!"); c.add (myButton, BorderLayout.CENTER); myButton.addActionListener (this); } public void actionPerformed (ActionEvent ex) { JOptionPane.showMessageDialog (this, “Beenz Beenz The Musical Froot"); } }

This should all be familiar stuff - we're not going over any new ground here beyond what we learned in second year programming. This is not a bean - this is simply a class that handles a particular element of functionality.

The act of converting an existing class into a Bean is a valuable exercise - as Java programmers, we may have built up a library of useful classes over our time with the language, and it would make sense for us to turn to these classes whenever we need to provide Bean functionality.

The first thing we need to do is take a look at the idea of a property.

Any class can be made into a JavaBean - it just needs to adhere to the software component specification. The JavaBeans framework allows for an object to be configured as a set of named properties, which represent the internal state of the component.

A property is not quite the same thing as an attribute, although they are often implemented in that way. The only thing required to setup a property is a pair of accessor methods. The naming convention for these is very strict - it is adherence to this convention that determines whether on not a class is actually a properly implemented Bean.

In fact, those of you who did Object Oriented Programming 2 will already be familiar with the format - it's a standard convention adopted all the way through the Java API:

public <type> get<Name>() { return <something> } public void set<Name> (<type> value) { <something> }

A property may be defined as read only (it only has a getter method implemented), or write only (it only has a setter method implemented), or as read and write (it has both a getter and a setter implemented). The of a property can be any primitive variable type, or any Java class.

The naming convention is strict - the name of the property must have its first letter capitalised after the set or get part. For example, a read-only property called Bing that returns a String value:

public String getBing() { return "Bing!"; }

Properties are usually implemented as public interfaces to private attributes. For example, if we wanted to make our Bing property something that could be changed:

private String bing; public String getBing() { return bing; } public void setBing (String value) { bing = vale; }

This is the most common approach used when setting up a property, but there are others. A close second is the evaluated property, which is calculated 'on the fly'. For example, we could evaluate the bing property to ensure that we always had a 'fallback' position:

private String bing; public String getBing() { if (bing == null) { return "Bing"; } return bing; }

As you can see, there is nothing mystical about a JavaBean - it's just a class that has a strict adherence to a defined naming convention. As we look more into the subject of JavaBeans in the next chapter, we'll see some of the neat things that it's possible to do with them.

Indexed properties work like normal properties, except that they are used to access specific elements of an array. They are implemented by providing the standard set and get accessor methods, as well as a pair of overloaded accessor methods that allow for specific elements to be set:

String[] bing; public void setBing (String[] bong) { bing = bong; } public String[] getBing() { return bing; } public void setBing (int index, String new) { bing[index] = new; } public String getBing (int index) { return bing[index]; }

Beyond this, there is no difference between implementing indexed properties and standard 'vanilla' properties.

As with any object in Java, a JavaBean can provide any number of constructor methods. However, one of the requirements of the software component definition is that it must in all cases provide a default, no argument constructor.

JavaBeans are quite unusual in terms of their object design in that they are not generally configured with a multiple parameter constructor. Instead, they are set up using the generic no argument constructor, and then configured with multiple property calls.

The last aspect of the software component definition for JavaBeans is that they must implement a particular interface - this interface is called Serializable and can be found in the java.io package. It is not important to know at this point why this is required, or what it actually does - we'll cover that in the next chapter. It doesn't even really need to be there - a bean will usually work perfectly well even if you don't implement the serializable interface. The specification however, does demand that it be implemented.

Implementing the serialization interface does not require you to add any extra code to the bean. As I say, we'll have cause to return to this subject in the next chapter.

Okay, so now we know what a JavaBean is - it's a typical Java class that also adheres to a strict naming convention. It's not very special, and it doesn't seem very exciting. We'll have cause to reassess that initial disappointment in later chapters.

As you may have noticed, the class above is almost written according to that basic convention - it's very nearly a JavaBean already! We have no properties to speak of - the JButton itself is an internal attribute and not something we want people to be able to change. It already has a default constructor method, so we don't need to add one - it's full of beany goodness right from the very start.

We need to implement the serialization interface, but that's no big chore - there's no code that goes along with that.

By now, I suppose you've rumbled the big secret - JavaBeans are not technically very interesting. In fact, there is almost nothing new in them at all as far as syntax goes.

Really, JavaBeans are only useful within a Builder environment, such as Borland's JBuilder... in fact, that's exactly where they are designed to be used. The strict naming convention is a consequence of the way builder environments access the beans. They can be dropped into the toolbox of the builder, and then dragged onto the form just like a JButton, or a scrollbar, or anything else that you may be used to from experience with other builder environments.

That's the real benefit of JavaBeans - drag and drop functionality. Once they've been drawn onto a form, you can set any of the properties through the IDE. Those of you with Visual Basic experience will understand what a time-saving this can be.

So, our class may already be most of a bean, but it's not very interesting. It would be great if there were some extra properties that let us define the way it behaved a little better - so let's add a method that lets us change the message displayed, and implement the Serialization interface while we're at it:

import javax.swing.*; import java.awt.*; import java.awt.event.*; import java.io.*; public class MyFirstBean extends JPanel implements ActionListener, Serializable { JButton myButton; String message; public String getMessage() { return message; } public void setMessage (String value) { message = value; } public MyFirstBean() { myButton = new JButton ("Press Me!"); myButton.addActionListener (this); add (myButton, BorderLayout.CENTER); } public void actionPerformed (ActionEvent ex) { JOptionPane.showMessageDialog (this, getMessage()); } }

It's still not a great bean, but it's a little better. If we were using a builder environment such as JBuilder, we'd even be able to drag and drop our bean onto a frame and configure it via the interface. The decadent luxury of a builder environment is not for us though, and so we won't look at that.

And there you have it - our first bean, implemented and incorporated into a graphical user interface with the minimum of fuss.

Of course, we're not even nearly done talking about JavaBeans - we've only looked at the simplest of examples. In the next chapter, we'll look at how we can incorporate events into our JavaBeans. We'll also talk about serialization, and why it is a Most Excellent tool for JavaBeans and beyond.

JavaBeans? Pah... piece of cake. Or perhaps a casserole, since beans are very rarely used as an ingredient in cake-based products. They are pretty easy to write though, since they are not a new development model, they're just standard classes with a little extra thrown in. As far as traditional coding goes, they have limited appeal - it is only within builder environments that standard JavaBeans really come into their own.

JavaBeans are just classes that are written according to a software component definition that states that they must:

1. Adhere to a standard naming convention with regards to publicly available properties.
2. Provide a default, no-argument constructor
3. Implement the Serialization interface

Once they've been written, they can be slotted into environments like JBuilder and used like any other Java GUI component. They can be dragged onto the form, resized (provided the component properties allow for that) and configured both at design and run-time. Pretty nifty!

Exercise One

MyFirstBean is pretty boring - it doesn't do much at all. Change the code so that every time the button is pressed, it displays a different message.

Exercise Two

Add a JTextField to the bean... when the button is pressed, the bean should display the text in the JTextField in the message dialog.

Further Reading

The following table details further reading on the topic in this chapter, and also any external resources that you may find useful.