Monolithic Applets vs. Multiple Independent Objects

Before we dive into the matter at hand, be advised that if you didn't read last week's column, you should link back for a minute and check it out. We introduced an applet, and now we're going to go into some detail about how it works.

When the applet starts up it makes the two text boxes you see, then connects to this Web server, downloads this Web page, and stores it in the lower text box. Then it scans through that text, looking for HTML tags (marked off with < and >)--storing them all in an array-like variable. It uses this to make a specialized button out of each tag.

Once the applet class itself is done with all that, it does nothing else. The rest of the work is done by the buttons themselves. Each button that we created has its own event handler. When a button realizes it's being pressed, it takes part of the text from the box containing the HTML (the text corresponding to its tag) and pastes it into the smaller, top box.

That is principally what we were referring to last week when we mentioned we'd made a Button subclass. Many of you who've programmed in other languages might think it strange that we did it this way; a more conventional approach would have been to put the applet itself in charge of taking care of business when the user clicks on something. It's centralized thinking; a lot of programs do it. It's common practice in the non-object-oriented world.

Why is our way better? A gigantic event handler within the applet class itself would've taken a lot longer to write (which increases the chances of writing an error into it), made the applet class bigger (which makes it take longer to download), and made the whole applet more difficult to change down the road (because the code that makes the behavior we want wouldn't be all within the same place). What we're doing is actually closer to the much-touted ideal of object-oriented programming, and in as much as this particular aspect of it is surprising to you, we've created a good example.

What are we really getting at? The text boxes aren't just tools for display, they actually contain (and are responsible for keeping) the information they show. The buttons aren't just extensions of a big master control program, simply relaying control information. They're self-contained independent entities, each containing its own relevant bit of information, and each with its own action to carry out. In our example, the applet class does play an orchestrating role, setting up the pieces and keeping them within its own display area, but this is a matter of convenience, as opposed to a design philosophy.

Our goal is to display some of the elegance of this design. It could be argued that because we use multiple classes to make up our applet, it actually takes longer to load than if we'd made one monolithic applet class, which is perhaps true: The Netscape class loader appears to load individual classes one at a time, and rather slowly at that. (This is particularly evident when loading applets that need dozens of classes to function. Regardless of their size, even over a fast network connection, the wait may be inordinately long.) One might also argue, strictly speaking, that there is additional overhead in the instantiation of a larger number of complex independent objects. Yet while we might foresee applets that need to be optimized down to the last bytecode, it's more likely that the advantages of this kind of design outweigh the disadvantages. When we return to modify this applet, you'll see why.

Once again, we've touched on the theme of program design. To recap, our main point this week has been to show a crucial difference between programs using a single, monolithic routine and those using a larger number of independent, "self-contained objects." It's a way of thinking, really, and one that we believe (often enough, at least) pays off--especially in Java.

We've only just begun to pick this applet apart. Once we've laid the groundwork for why we've done what we've done, in the next issue, we'll start examining exactly how we did it.

Past installments of Java Jolt