To develop an application using Naked Objects, all that the developer
writes are the naked objects: the business objects that
model the domain. Each class of business object (for example, Customer,
Product, and Order) must be written as a Java class, and must implement
an interface called NakedObject that is provided by the framework. The
simplest way to do this is to declare each of your business classes to be
a sub-class of the AbstractNakedObject class provided with the
framework. The programmer must write the necessary code to specify each
business object's attributes, associations with other business objects,
and business behaviours. The code must follow a few simple conventions,
but in general the business objects are coded in the same way that
behaviourally-complete business objects would be written for the business
model tier of any multi-tiered system.
When the set of business classes is compiled and run, the framework's
generic 'viewing mechanism' provides the user with a view of the business
objects in a form like that shown in the screenshots below.
Individual business object instances show up as icons; the style of the
icon indicates which class it belongs to, and a unique title (specified
by the programmer and usually derived from one or more of the object's
primitive attributes, such as the name, date and reference number)
distinguishes that instance. Any of these icons can be double-clicked to
open a more detailed view of the object's attributes and associations
with other objects (which show up as icons in their own right).
To develop this early-stage prototype for an expenses processing
system using the Naked Objects framework, the developers had only to
write the code specifying the 'naked' business object classes. These
are shown in the classes window. Individual instances take the icon of
their class by default. They can be opened to reveal their attributes
and associations, dragged and dropped onto other objects or specific
fields, and right-clicked to reveal a pop-up menu of actions that
includes both generic operations and business behaviours.
|
Right-clicking on any object will produce a pop-up menu of actions
(instance methods) that users can invoke on that object. Right-click
on a Customer object and you might be able to 'communicate'
with that customer (via one of the customer's communication addresses) or
perhaps 'assess the value' of the customer to the business based on past
orders.
In addition to these business methods, the pop-up menu may offer the
user different ways to view the object. For example, you might be able to
view a Product object as a photographic image; a collection of similar
objects as a table, rather than a list; or a set of numerical values as a
graph. And if the object has spatial coordinates associated with it (e.g.
Latitude and Longitude) then you might want to view it on a map or
graphical layout. These viewing options are created automatically, based
upon the type of the object: they do not have to be written by the
developer. (The framework can be extended to create new ways of
visualizing an object, but this should not be necessary for a
straightforward application).
As well as via pop-up menu actions, behaviours can also be initiated
by user drag and drop actions. The user can drag an object onto another
object, which will trigger a pre-defined operation involving the two
objects; or drag an object into a specific field within another object,
usually to specify an association between the two. If the user attempts
to drop the wrong type of object, the drop-zone will flash red and the
drop will not work. Similarly a menu action may be greyed-out if the
action is impermissible, usually because of the current state of the
object. The set of menu actions, attributes and associations that the
user sees may also be customized according to the role(s) that they
fulfil.
In addition to the individual instances, and collections of
instances, the system presents the user with a direct representation of
the classes themselves - shown in the screenshot as the Classes window.
This is where the user goes to invoke behaviours that don't belong to a
single instance: such as to create a new instance of that class, to find
a specific instance, or to list the instances of that class that match
some specified criteria.
That's all there is to it. Everything the user does is a direct
operation upon one of the business objects, or its class. There is
nothing getting between the user and the naked objects. There are no
top-level menus, no scripts. There aren't even any dialog boxes.
Naked Objects encourages the design of behaviourally-complete objects
in two ways. First, positively: the concrete visual representation of the
business objects helps users identify with the object model and makes it
much easier to envisage behaviourally-complete objects. Second,
negatively: if there is no other way to build business functionality into
the system, then the
designers are forced to associate all required behaviour with a business
object.
|