Naked Objects
By Richard Pawson and Robert Matthews

Programming with Naked Objects

In this section we will look at how to write a business system using the Naked Objects framework.

Most of the code examples in this section are taken from the Executive Car Services (ECS) application, the complete code for which is distributed with the Naked Objects framework.

We will start by looking at the anatomy of a naked object - the interface that it must present to its external users. Naked object classes are written in Java and build on Java's inherent structure by adopting certain coding conventions. Because we name and structure methods in a standard way, the framework can recognize the fields and behaviours of an object and make those objects available to the user, identify them and manipulate them.

We then look at how to make your naked object classes available to users in the form of a simple standalone application that is suitable for exploration and testing.

The third part looks at making the same objects available as part of a finished business system. This section addresses the issues of sharing objects between multiple users, making the objects persistent (typically via a database), and handling transactions.

In the fourth part we look at writing unit and acceptance tests. We show how Naked Objects makes it feasible to write your acceptance tests before you commence writing any of the operational code.

The last part looks at the detail of coding business functionality into a business object. This includes manipulating value objects and collections inside your methods, building more complex titles for an object, and using About objects to implement business controls.

In order to follow this section you will need to have some familiarity with Java already. Our aim in developing the framework was to build on the way Java classes are defined, make use of recognized good practices and minimize the number of new restrictions. Most of the burden of using the objects - displaying, distributing and persisting them - is therefore shifted onto the framework, leaving you free to code just the business objects.

Throughout this section we often talk about naked objects from the user's perspective. For example, we talk about one-parameter action... methods as enabling one object to be dropped onto another. This way of describing naked objects comes naturally because the objects we are defining are the objects the user manipulates. But it is important to understand that the naming convention required by the Naked Objects framework is not in fact directed at the user interface. Those same one-parameter action... methods might also be called by other objects or by a batch program with no user interface. The coding conventions are our way of exposing the object, laying it bare, making it naked. Then the naked object can be seen by the system, and hence shown to the user.

Furthermore, the style of graphical interface that we show throughout this book is the one generated by the first viewing mechanism that we have written. We expect to write other viewing mechanisms that will take the same business objects and render them in quite different styles - perhaps via an HTML-only browser interface, or even a via speech synthesiser and voice recognition system.

If you have not already used Naked Objects, we suggest that before working through this section you follow our step by step instructions for downloading and installing the framework and then developing a very simple application from scratch.

Notes for experienced Java programmers

If you are an experienced Java programmer then you will be able to work through much of this section fairly quickly. But be aware that the coding for Naked Objects does differ in a number of small but important ways from writing Java classes in general:

  • All fields usable by the user need to be of type org.nakedobjects.object.Naked. The framework does not know how to display or persist the standard Java types. The framework does provide a number of generic Naked types such as TextString, Money, WholeNumber and Date (all part of the org.nakedobjects.object.value package), which both encompass and extend the types provided by Java.
  • It is important to access variables through their accessor (get... and set...) methods rather than directly. The persistence mechanism relies on such methods to store away and reload the object's data.
  • To create an intialized and persistent object, use the factory method createInstance. New instances of business objects should not be created using just the standard Java new operator - this would not initialize them properly. Related to this, a persisted object's constructor will be invoked every time it is restored.
  • Every persistent object must have a unique ID that does not change between instantiations. The equals and hashCode methods are based on this ID and should not be changed.