Naked Objects
By Richard Pawson and Robert Matthews

Making the objects available to the user

Incorporating naked objects into a simple test application

The following example from the ECS system extends the Exploration class to start up an exploration application. Here you can see the registration of the business object classes (in the classSet method) and how the application is started in the main method:

package ecs.delivery;

import org.nakedobjects.Exploration;
import org.nakedobjects.object.NakedClassList;

public class EcsExploration extends Exploration {
    public void classSet(NakedClassList classes) {
        classes.addClass(Booking.class);
        classes.addClass(City.class);
        classes.addClass(Location.class);
        classes.addClass(CreditCard.class);
        classes.addClass(Customer.class);
        classes.addClass(Telephone.class);
     }

    public static void main(String[] args) {
        new EcsExploration();
    }
}

Starting an application in this way does not make use of a persistence mechanism. This is intentional so that it is easier to test an application whilst the object definitions are rapidly changing. It is possible to specify a persistor in this test environment, but it can be more useful to have the application set up a known set of objects from scratch each time it starts.

You can do this by overriding the initObjects method, as shown here for the ECS example. This creates a list of seven cities and two customers - a more realistic demonstration would need more. (The objects must be created via the Exploration class otherwise they will not be added to the framework's (transient) object store and therefore will not be made available to the user.)

public void initObjects() {
    String[] cities = {
        "New York", "Boston", "Washington", "Chicago",
        "Tampa", "Seattle", "Atlanta"
    };
				  
    for (int i = 0; i < cities.length; i++) {
        City newCity = (City) createInstance(City.class);
        newCity.getName().setValue(cities[i]);
    }

    Customer newCustomer;

    newCustomer = (Customer) createInstance(Customer.class);
    newCustomer.getFirstName().setValue("Richard");
    newCustomer.getLastName().setValue("Pawson");

    newCustomer = (Customer) createInstance(Customer.class);
    newCustomer.getFirstName().setValue("Robert");
    newCustomer.getLastName().setValue("Matthews");
}
Icons

The images for the icons are sought within a directory called images which must be located within the working directory - the directory that Java is running from. The image files are matched to the names of the classes with the addition of '16' or '32' and an extension of '.gif'. For example City16.gif and City32.gif are the two images for the City class. The numbers refer to the size of image - 16x16 and 32x32 pixels respectively. Images of both sizes are required by the framework.

You can also place these images within the resources that will be made available to the JVM - place them in the .jar file alongside the class files when you distribute your application. However, they must still be held within a sub-directory called images.