Naked Objects
By Richard Pawson and Robert Matthews

The anatomy of a naked object

Naked object classes

Here is a typical class declaration for a business object class written using the Naked Objects framework. It is shown here without any method bodies, and with the required members in bold. The zero-parameter constructor is shown to reinforce the point that one is always required (although if you don't declare any other constructors then Java will provide this one for you.)

import org.nakedobjects.object.AbstractNakedObject;
import org.nakedobjects.object.Title;
import org.nakedobjects.object.control.About;

public class Parcel extends AbstractNakedObject {
    public static final long serialVersionUID = 1L;

    public static About aboutParcel() {} 

    public Parcel() {} 

    public About about() {} 

    public void created() {} 

    public Title title() {}

The class variable is the version number for this serializable class, which is used when the object is serialized (as happens when it is transferred across the network). Although there is little that will cause serialization to fail, the default serial numbers can be different on different JVMs, so it is good practice to set this variable up for each new class. (However, to keep things brief we do not show this in the examples that follow.) As the Naked Objects framework uses quite a coarse-grained serialization algorithm, this serial number can be set (to any arbitrary value) and left, even when the class is changed.

The two about... methods are used to control the accessibility of the class and its instances.

The created method is only called following the creation of a new logical instance of the class and not every time that that logical object is recreated in memory by the persistence mechanism. By contrast, the constructor will be called every time Java instantiates that particular persistent object, which will happen each time the object is retrieved from the persistent store. Thus, the created method is where you would put any code for initializing a business object.

Making a class uninstantiable

By default, users will be given the ability to create new instances of any business class. To prevent this you can add the static about method to your class. For example, in the ECS application the set of City objects is fixed by means of the following code:

public static About aboutCity() {
    return ClassAbout.UNINSTANTIABLE;

(org.nakedobjects.object.control.ClassAbout is a special type of org.nakedobjects.object.control.About object provided by the framework.)

In consequence, the pop-up menu on the Cities icon will show New Instance... as disabled. Dragging the class onto the desktop or into a field to create an object will not work either.

The About can also be used to prohibit access, by making the class invisible to certain types of user, or to all users.

Making an object read-only

It is also possible to control access to individual instances. An object can be made unchangeable, so that all the fields are set to read-only; and it can be made inaccessible, so that it will not appear on the screen. This is done through the about object method (as opposed to the about class method such as aboutCity in the example above). The following method, again taken from the City class, makes any instance of city un-editable:

public About about() {
    return ObjectAbout.READ_ONLY;
Class names

Classes are usually represented to the user in two places when Naked Objects is run. The first, and most obvious, is the list of classes. The second is in each empty field, where the class indicates the type of object that can be placed in that field. The screenshot below shows both. Note that the Customer field takes a Customer object and the Pick Up and Drop Off fields both take Location objects.

The titles shown for the classes are automatically generated from the name of the class by removing the package name, adding spaces in front of subsequent upper case letters, to separate the words, and adding an 's' on the end. If the class name takes an irregular plural then you can use the class method pluralName to specify the plural version manually. For example, the following code shows the method set up to return the correct plural for the class Calf:

public static String pluralName() {
    return "Calves";

You can also specify a class title to be shown to the users that is different from the name of the Java class, by using a singularName method. This could be wise in languages that use accents and ligatures. As Java source code is compiled using Unicode instead of ASCII, it is possible to use both of these within identifiers, but it is not recommended because identifiers are easily mis-spelt or corrupted when source code files are transferred. Instead, give your identifiers simple ASCII names, as shown in the example below, which embeds the german 'ä' into the plural string as a unicode character:

public class City extends AbstractNakedObject { 
    public static String singularName() {
        return "Stadt";

    public static String pluralName() {
        return "St\u00e4dte";