ECLIPSE IDE Tutorial - Creating A Resource Class Composed of Object Lists

In the last tutorial, " ECLIPSE IDE - Have a List of Items? Make use of the ArrayList JAVA Package", we experimented with the ArrayList class from the java.util package. In this tutorial we return to "full fledged" coding of our evolving application for our car rental agency. Continuing to use the "test first" method, we will create array lists for the two classes which make up our object types, cars and renters (best identified through the BillingAddress class, companyName field).

At the end of this tutorial,we will be ready to implement add and remove methods to add and remove object for two array lists we created.

The snapshot which follows show a screen we have started to become very familiar with, the create JUnit test screen arrived at by selecting File> New> Other> JUnit> JUnit Test Case. The test case to be developed is named CarRentalResourcesTest. Any name will do but this name does reflect what the array list objects represents: the Car class, the tangible assets of the agency, and the BillingAddress class, the intellectual or information property.

The first thing required is the creation of the constructor method. The statements required are as follows:

• create a new object of the class CarRentalResources, as follow

CarRentalResource crr1 = new CarRentalResource("Test");

• test that the name field (as yet undefined) is matches the string "Test":

assertEquals(crr1.name, "Test");

• the next two lines are new and require some explanation

assertTrue(crr.Car instanceof ArrayList);

assertTrue(crr1.BillingAddress instanceof ArrayList);

assertTrue expects a Boolean value, that is the argument passed to it must evaluate to either true or false. The instanceof is an operator which returns true if, in this case the crr1.BillingAddress object is an object of the type ArrayList. In other words, are we working with an object of the type ArrayList.

Next, use ECLIPSE "quick fix" to create the CarRentalResource class.

Continuing to "step through" the compiler errors, next hovering over the field in the statement:

CarRentalResources crr1 = new CarRentalResources("Test");

requires the creation of the constructor as suggested by "quick fix" in the following snapshot.

Two types of errors remain at this point. One type relates to the undefined fields which are not defined in the constructor. We illustrate this with the example for the ECLIPSE "quick fix" suggestion for the name field. The second type of error which occurs relates to ArrayList. ArrayList is defined in the java.util package. Import this package in order to use the short name, ArrayList rather than the fully qualified name, java.util.ArrayList which would otherwise be required.

The snapshots which follow illustrate the use of "quick fix" for fields (illustrated with the name field as an example) and the import suggestion for ArrayList.

We turn our attention to the constructor method. The following items need to be performed:

• Change access methods for the fields. As a review there are three access methods which we defined in a previous tutorial: public, which indicates the method is available to any class; private, which indicates that access is restricted to this class; and, no modifier specified, means "package protected", other classes within this package has access to the fields.

• Check that generic type is specified for ArrayList. Depending upon the way the previous set of errors were corrected, ECLIPSE will generate a different set of suggestions through "quick fix'. Again, as a reminder, the new concept of generic type was noted (e.g. ArrayList<String>) and the benefit of specifying this as a way of trapping errors via the compiler if an attempt to add inappropriate objects to array lists was made. Therefore, its a best practice when changes are made to save the appropriate file after each change whether it be the source class or the test class. In this case we also want to make sure that the array lists have the generic added to specify the apporpriate class type. In our application that is ArrayList<Car> and ArrayList<BillingAddress>.

The tests in these tutorials were developed in a JUnit 4 test environment. Since this is a set of tutorials for relative new comers to ECLIPSE IDE and perhaps JAVA as well, adding test cases for a JUnit 3 environment would seem to add undue complexity to a somewhat complex product. There is no real advantage in backpedaling to JUnit 3. JUnit 4 has a number of advantages over JUnit 3. The annotations, such as @Test removes the need to identify test code in a more obscure way.

If, one is looking at these tutorials and know that their work may involve working in a JUnit 3 environment some research may be beneficial. Two points are most important: 1) JUnit 3 requires that test class names are prefixed with the word test; and 2) the @Test annotation in JUnit 4 required some actual statement coding. There are a number of web forums that disucss these issued..

These are very difficult items to try to enumerate so they will be remembered are consistently used. Keep in mind that ECLIPSE is using highlighting, color, underling, and warnings to keep your development on track. For example, local variables are displayed in black, a method which is overridden will have a green caret in the source left hand margin, and reserved words will be displayed in purple. These are a few of the ways ECLIPSE can either help the developer avoid a coding error or act as a clue when an error does occur.

In this tutorial, we continue to follow the "test first" methodology. This results in us using ECLIPSE "quick fix" repeatedly to "backfill" fields and methods are required. However, the benefits of having the test case as a specification for development and as a way of enforcing in an automated way the fact that the application documentation via the test itself is always current.

Any tedium in "quick fixing" errors is also offset is "quick fix" does not make typos.If the suggestion made by "quick fix" and selected by the developer is appropriate, the code generated is syntactically correct.

Coming up there is quite a bit to do to finish the methods necessary for full functionality of the lists. Among the methods we will look at implementing are the following:

addCar(), removeCar() and addBillingAddress() and removeBillingAddress() - these are fundamental methods which will be created in the following tutorial. Following this next tutorial we will then be able to proceed with the remaining methods, namely:

checkoutCar(), checkinCar() - cars are rented and returned. Methods to associate a car with a company rental must be kept up to date.

getAvailableCars(),- we must know what cars are available for rental. Having a handy list let's both the rental agency and the potential customer know what their options are.

getUnavalibleCars(),- cars may be unavailable for reasons other than their rental (e.g. repair, servicing)

getCarsForBillingAddress() - for the billing department (and other uses) there is a need to know what cars are rented to what company.

This outlines the work ahead. Till next time!