NAKED OBJECTS APPROACH

The Naked Objects Approach

Additional Requirements

Table of Contents

Introduction3

Discussion and Analysis5

The Naked Objects framework9

Guidelines for Designing Naked Object Systems10

The early work on the DSFA's business object model10

Disadvantages of the Object13

Conclusion13

References14

The Naked Objects Approach

Introduction

The inventors of object-oriented programming conceived 'objects' as representations of the entities that model a chosen domain, with each object encapsulating the state of that entity (i.e. its attributes, including any relationships to other objects) together with the behaviours associated with that entity. In other words, objects were originally conceived as being 'behaviourally complete'. That term is not meant to imply that an object provides conceivable behaviour that could be required of it in any context. Rather, the term simply implies that within the context of a given application, all the functionality associated with a given entity is encapsulated in that entity, rather than being provided in the form of external functional procedures that act upon the entities.

Today, however, most object-oriented designs, and especially object-oriented designs for business systems, do not match this ideal of behavioural-completeness. Whether by deliberate design or not, the objects representing the business entities (such as Customer, Product, and Order) are often behaviourally-weak. They typically have methods for updating the object's attributes and relationships to other objects; possibly they have methods for implementing constraints on those attributes or relationships; and perhaps they have methods for implementing a few simple processing functions on the object. However, much of the business functionality required for the application is typically implemented in procedures or 'controllers' that sit on top of these entity objects (Constantine, 1993).

It has been demonstrated that this approach yields four benefits:

The resulting systems are more agile, meaning that they can more easily be modified to accommodate unforeseen future business requirements. This is primarily because the naked objects are forced to be behaviourally-complete.

The resulting systems provide the user with a more empowering style of interaction.

The development cycle is significantly shortened, because the presentation layer is generated automatically from the domain object definitions, and because the overall design is simplified.

The naked objects provide a common language between application developers and users, which facilitates the early stages of requirements gathering and domain modelling.

Building systems using naked objects implies some sort of software framework (Constantine, 1996).

('Framework' is used here in the sense defined by Deutsch i.e. a set of classes that forms a skeleton around which an application is constructed). In this case the framework must provide, at minimum, two capabilities. The first capability is an implementation of the generic presentation layer (i.e. a set of classes that fulfil the roles of View and Controller in MVC architecture). The second is some mechanism whereby that generic presentation layer identifies the domain objects and their behaviours, in order to render them available to the user.

Two examples of such frameworks have emerged during the course of this research, the Naked Object Architecture and the Naked Objects framework, both explicitly designed to support the concept of naked ...