Naked Objects
By Richard Pawson and Robert Matthews
Introducing 'naked objects'
The Naked Objects framework
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.
Copyright (c) 2002 nakedobjects.org You may print this document for your own personal use, or you may copy it in electronic form for access within your organisation, provided this notice is preserved.