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.
|