Part 1: The Case for Naked Objects: Getting Back to the Object-Oriented Ideal
Part 2: Challenging the Dominant Design of the 4-Layer Architecture
Part 3: Write an application in Java and deploy it on .Net
Part 4: Modeling simultaneously in UML, Java, and User Perspectives
Part 5: Fat is the new Thin: Building Rich Internet Applications with Naked Objects
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Most contemporary approaches to business systems adopt a four-layer model (as shown below):
- The presentation layer defines the screen layouts and captures user input.
- The controller layer (sometimes called the 'task', 'process', or 'application' layer) contains an executable script for each business task that the user is expected to perform.
- The domain model layer defines the key business objects, their attributes and relationships.
- The persistence layer stores the state of the domain objects, most often in relational database tables.
There are different ways to implement each of these layers, and different ways to split them between client and server platforms. The four layers will also draw upon various generic technologies and services, some of which can be envisaged as layers in their own right. What distinguishes the four layers described above, however, is that they all have to be designed and developed explicitly for each application.
New database technologies such as JDO and Hibernate have introduced the concept of a 'transparent' persistence layer, eliminating the need to develop that layer explicitly, and thereby improving both the initial development productivity and the maintainability of the resulting application.
GUI toolkits and frameworks have reduced the coding effort associated with the presentation layer; the emerging concept of rendering engines seeks to derive the presentation layer automatically from the controller layer and/or the domain model.
The concept of 'naked objects' can be seen as a continuation of this trend, although it is more radical in nature. With the naked objects approach, building a business system consists solely of defining the domain objects: Customer, Product, Order and so forth. These domain objects are then rendered directly visible to, and manipulable by, the user. All user actions consist of creating or retrieving objects, specifying their attributes, forming associations between them, or invoking methods on an object (or collection of objects) - in other words through a truly object-oriented user interface.
It follows that for this to work, the domain objects must be 'behaviourally complete': any functionality required of a customer (such as the ability to communicate with that customer, to authenticate the customer when they call, or evaluate their credit risk) must be implemented as methods on the Customer object.
Most programming is now done in object-oriented programming languages such as Java; object orientation has made much less impact on the high level design. Most business systems still separate procedure from data (i.e. the controller layer from the domain layer) even if both are implemented using object-oriented languages or technologies. Indeed most of the recent trends in business system architecture, from component-based development to web-services, reinforce this tendency to separate procedure from data. This kills the real benefits that object-orientation has to offer as a design approach.
The naked objects approach encourages the design of truly object-oriented business systems. It does so in a negative sense, by making it very difficult for the designer to separate procedure and data; it does so in a positive sense, by making the idea of behaviourally-complete domain objects very concrete and very fast to develop.
The theoretical concept of Naked Objects grew out of my research into 'expressive systems', object-oriented design and agile software development approaches, conducted over more than ten years. (Naked Objects is the title of my PhD thesis, now finally completed and awaiting examination.) It first became a practical possibility when Robert Matthews wrote the Naked Objects Java framework.
The framework uses Java's reflection capability to determine the methods of any business object and render them visible on the screen by means of a generic viewing mechanism. All this takes place dynamically at run-time - there is no code generation taking place. A typical screenshot from a Naked Objects application is shown below. Objects are shown as icons, which can be opened to view their attributes and associated objects, and right-clicked to view their publicly-accessible methods. (The icons on the left hand side of the screen represent the classes - they provide methods for creating a new instance of that class or retrieve existing instances). The screen uses the default viewing mechanism, but there are now alternative viewing mechanisms appearing for the framework, all of which work transparently.
Robert and I wrote a book about the framework and the approach it embodies, which you can order from Amazon or read freely online on the website we founded: www.nakedobjects.org. The Naked Objects framework is freely available under the open source GPL license, or under a commercial license for those who want commercial support or to write proprietary applications on top of the framework. More than 10,000 copies of the framework have been downloaded to date, and it has generated a great deal of discussion in various forums. If you search for "Naked Objects" in Google, most of the first few hundred hits will point to discussions of this framework, and not to what you might otherwise expect! (We do, occasionally, though, find that the name gets blocked by the more aggressive email content filters!)
I originally predicted that the naked objects approach should deliver four benefits:
- Higher development productivity through not having to write a user interface
- More maintainable systems through the enforced use of behaviourally-complete objects.
- Improved usability deriving from a pure object-oriented user interface
- Easier capture of business requirements because the naked objects would constitute a common language between developers and users.
Hard data is now beginning to emerge - both from real applications and from laboratory tests - in support of these predicted benefits. And two further benefits have also emerged from this practical experience. The first is improved support for test-driven development: the Naked Objects framework now has a dedicated test harness that makes it very easy to write executable user acceptance tests in the manner advocated by Extreme Programming, though seldom practiced due to the difficulty of writing such tests for systems with conventional graphical user interfaces. The second unforeseen benefit was that the naked object approach would facilitate cross-platform development. With the Naked Objects framework it is already possible to write a business application in Java and compile it, without modification, for the .Net platform.
The editors at TheServerSide.com have invited me to produce a series of articles about the naked objects approach and its benefits, with 'as much emphasis as possible on real examples'. Most of these will be written either with Robert Matthews, or with Dan Haywood, co-author of the book Better Software Faster (http://www.bettersoftwarefaster.com/) and one of the most active members of the Naked Objects development community.
The next article describes a controlled experiment in which Dan and I took an existing Java application that had been implemented in the classical four-layer architecture and re-implemented it from scratch using the Naked Objects framework. It provides hard data on the claims for improved productivity and improved maintainability.
In subsequent articles we'll be looking at the evidence to support each of the other claimed benefits, and, from time to time, comparing the naked objects approach with other emerging technologies and trends.