Simple Programming Tip #1 by Charlie Calvert

Abstract: This article contains the explication of a simple programming tip that can be read in a few minutes: Avoid writing code that does anything substantial inside a visual container. Instead, create separate classes for your working code.

Simple Programming Tip #1 by Charlie Calvert

Copyright ?2003 by Charlie Calvert

In this article I will describe the first of several simple programming tips. The discussion and code in this article is generic, and applies equally to C++, CSharp, Delphi or Java programmers.

The tip for this article is easy to describe: Avoid writing code that does anything substantial inside a visual container such as a Java JPanel or JDialog, or a Delphi/C++Builder TForm or TFrame. Instead, write code inside separate classes designed for a single, simple purpose.

Of course there are times when it is appropriate to break any rule. After all, what is the point of having a rule, if there won''''t be occasions when you break it? Needless to say, the smaller and simpler your application, the less need there is for rules of this type. But in big applications, rules like this are the keys to the kingdom!

The Danger of Click and Code

Borland was among the companies that pioneered the now popular options that allow you to drop a component such as button on a visual container, then double click on that component, and immediately begin writing event handling code. The beauty of this system is that it allows you to write code quickly and easily. The danger is that it can lead you down the primrose path that leads to unmaintainable "write once, read never" code.

The solution, of course, is not to abandon visual programming, but rather to adopt intelligent programming. When you create a new visual container, the first thing you should do is create at least one secondary class designed to contain your real code.

Suppose, for instance, that you want to create a visual container that will allow the user to view data. In particular, suppose your container will show the results of parsing an XML file that contains information about the Voyager I and II spacecraft.

Data of this kind is likely to be fairly complex. For instance, you would want to provide controls for seeing data that applies to Voyager I only, or to Voyager II only. Likewise, you would want to allow the user to see data about a particular planet visited by the spacecraft, such as Jupiter, Saturn, or Neptune.

Without going into details, it is easy to see that you are going to have to write a substantial amount of code that involves extracting data from your XML file. The neophyte visual programmer will write that code directly inside a button response method:

void MyButtonResponseMethod_actionPerformed(ActionEvent e)
{
	// Code to parse file added here
}

Suppose the code inside this method allows you to sort data according to the planet you are interested in investigating. The programmer happily writes a few lines of SAX based code, and seemingly has a solution to their problem.

But it is precisely at this moment that the ax falls. Whomp! Down it comes, cutting off the programmer of a large project from any hope of ever writing code that can be maintained or reused.

Let''''s follow this hapless programmer just a little further, to see the extend of the damage. The next step in this application''''s development might be to add a routine for displaying data sorted by findings made exclusively by either Voyager I or Voyager II. So another button response method is created, and now the user has two options:

1. Sort by planet

2. Sort by spacecraft

So far so good. But what if the user wants to simultaneously sort by spacecraft and by planet? The all too common solution to this problem is to create a third button response method that contains rewrites of the code in the Sort by planet response method and the Sort by spacecraft response method! This is a disastrous situation, in which duplicate chunks of code begin to appear. If a bug is found in the Sort by planet method, then the fix will also have to be applied to the duplicate code found in the Sort by spacecraft and planet method.

Some will laugh and say: "Oh, but I would never do anything so stupid!" And yet, I assure you, intelligent people do things exactly that foolish.

But let us suppose that the programmer is wise enough not to make such an error. Seeing the problem on the horizon, they move the code for sorting by spacecraft and planet to their own unique methods inside the visual container class. In pseudo code, the declaration for such a class might look something like this:

public class MyVisualContainer
{
	void _SortByPlanet_actionPerformed(ActionEvent e)		
	void _SortBySpacecraft_actionPerformed(ActionEvent e)
	void SortByPlanet()
	void SortBySpacecraft()
	void SortByPlanetAndSpaceCraft_actionPerformed(ActionEvent e)
}

The problem here is that the MyVisualContainer class is already starting to take on too heavy a burden! Like Dr. Jekyll and Mr. Hyde, it is beginning to lead a double life. Is it a simple visual container, or is it a XML parser? Only its hairdresser knows for sure!

The proper structure for code of this type should look something like this:

public class MyVisualContainer
{
	void _SortByPlanet_actionPerformed(ActionEvent e)		
	void _SortBySpacecraft_actionPerformed(ActionEvent e)
	void SortByPlanetAndSpaceCraft_actionPerformed(ActionEvent e)
}

public class MyVoyagerParser
{
	void SortByPlanet()
	void SortBySpacecraft()
	void SortByPlanetAndSpaceCraft();
}

The methods inside the container should feature only a few lines of code that call the working code in MyVoyagerParser. With today''''s compilers and CPU''''s, the overhead of adding this extra class will not cause a noticeable, or in many cases even measurable, hit to the performance of your application. As mentioned earlier, the best course of action is to block out the declaration fro MyVoyagerParser right at the start, as soon as you open the source for MyVisualContainer.

The Advantages of Intelligent Programming

In the previous section, I outlined some of the dangers of adding complex code to the button or menu event handlers. Let''''s now talk about some of the advantages of this type of coding.

Suppose you want to reuse the code you have written in a new application with a different interface. If you wrote your code properly, then your port to a new type of application will be easy. For instance, in the example at the end of the last section, you could simply reuse the MyVoyagerParse class. Just plug it in to your new app, calling it with a few simple lines of code:

MyVoyageParse->SortByPlanet();

But reuse is only half the story. The other big advantage of this type of programming is that it helps you simplify your code.

We have already seen that a visual container class can quickly become overburdened by trying to support too much functionality. Consider what happens if you want to

[1] [2]  下一页