The Naked Objects Framework

The Naked Objects Framework - as described in the Naked Objects Book, by Richard Pawson, Robert Matthews: [ISBN 0470844205], and available for download from their web site www.nakedobjects.org

The Naked Objects Framework is a generic implementation of a Direct Manipulation interface for your (Java) business objects. It exposes your Behavioraly Complete business objects (see Behavioral Completeness) to the user for Direct Manipulation by the end users, through a standard, generic, automatically generated user interface.

Advantages:

Saves development time and money: You implement business objects with user-visible behaviors; user interface and persistence are provided for you.

Empowers users:

The system's model is directly visible and manipulatiable by the users.

Objects and functionality can be manipulated in a variety of ways to achieve the intended work result, enabling the users to pursue their work in the most effective way for them at the time, rather than being constrained by predefined scripts.

Disadvantages:

Primarily useful for "expert" users -- in the sense that they have to understand the business model and the business processes they are trying to achieve. This approach won't be as useful for users who need heavy scripting and hand-holding to successfully accomplish a process.

The Naked Objects Framework does "Auto Gen Crud Screens," but that's not the main reason to use it. The Naked Objects Framework restricts the user interface to Direct Manipulation of the business objects you define. Thus, it imposes a discipline and simplicity on your design that forces you to make your data and operations meaninful to your users -- because they'll be directly visible and manipulatiable by your users.

Naked Objects is a radical Design Pattern that has users using Direct Manipulation of program objects instead of having a User Interface between the user and the system objects. The basic idea is that most user interfaces get in the way by intervening between the users and the actual system objects, enforcing process oriented interactions and introducing UI - object synchronization problems. Giving the user the ability to interact directly with the objects and enforcing a 1:1 relationship between what the user sees on the screen and the objects used to represent them allows the users to become problem solvers rather than process followers. This pattern increases flexibility and empowers the users to find creative ways to solve problems.

The Naked Objects toolkit is available from www.nakedobjects.org


The "Naked Objects" book, by Richard Pawson, Robert Matthews: [ISBN:0470844205]

(...as printed and distributed on dead tree carcasses. ;-)

"In line with our philosophy of making our ideas freely-available we have put the full text of the book on-line.", say the authors.

http://www.nakedobjects.org/static.php?content=content.html

(At the moment, the images in the last section of Appendix A are missing from the online version. So... Go buy the real book! ;-)


Articles, books, and other descriptive material:

"The Naked Object Architecture Series" articles at The Server Side:

http://www.theserverside.com/articles/article.tss?l=NakedObjectSeries

discussion:

http://www.theserverside.com/news/thread.tss?thread_id=23548

The topic is explored in some more detail at www.nakedobjects.org and there was an article in JAVAPro magazine (www.fawcette.com ).

[Free subscription required to read the whole article. First page does not require subscription/login.]

Discussion thread on the yahoo "extremeprogramming" list: groups.yahoo.com



The Naked Objects Framework makes it easy to very quickly create projects that make use of the Naked Objects design pattern. However the toolkit is not fully fleshed out yet and it needs lots of work before it will be truely usable. On the other hand, there does seem to be a small developer community exchanging furtive messages on the Naked Objects developer mailing list.

The pattern is an old one that certainly floated around the early object communities working in both Lisp Language and Smalltalk Language, though the implementations probably favored direct manipulation by developers themselves rather than users. The specific framework suggested on nakedobject.org seemed to have some fresh ideas. Let's reserve the wiki word, Naked Objects, for this framework and the philosophy that goes with it. Let's call similar frameworks Direct Manipulators and explore their features and attributes on that page.


One interesting instance of this in the Lisp Language back in the 1980s was Information Lens and subsequently Object Lens from Mit Sloan School.

See Hay Stack -- which seems to be the most recent incarnation of these ideas.


This seems to be a GUI in the true spirit of OS/2 Workplace Shell desktop.

I thought so too. I actually created this page from an OS/2 offshoot, eComStation :)

Some of the examples in the Expressive Systems book were eerily similar to the "sandwich" demo that International Business Machines used to demonstrate in the early days of OS/2's Workplace shell.

Part of the reason that I like Naked Objects so much is that it provides some of the features I'm used to from OS/2 and Newton OS on other operating systems.

A Naked Object regular is Dave Roberts, of IBMs Ease Of Use. He discusses their involvement with OS/2 in this thread www.nakedobjects.org

-- Ged Byrne

Naked Objects was developed by Robert Matthews and myself. Recently, Dave Roberts who was indeed on the original Common User Access team has gotten quite interested in Naked Objects and we have both learned much from talking to him. The very strong similarity between the Naked Objects UI and CUA is, to date, coincidental. However, there are some ideas from the original CUA demos (which Dave showed us) that we now intend to copy. Interestingly, however, the original CUA documentation states clearly that the strongly object-oriented user interface on CUA is *not* a reflection of the underlying structure of the application. The big breakthrough in Naked Objects was not the UI (had we been more familiar with the original CUA work at the time we might have copied it wholesale) it was realising that this could be a simple reflection of the underlying code structure.


Some critics of the Naked Objects framework have not noticed that the system is designed to allow for multiple UIs. I have been developing a Swing-based system, called Iduna, that permits alternative viewers to be composed on the fly.


Isn't this just a kind of Visual Programming (from the User's perspective) ?

I'd say yes, except that the users aren't programming: They aren't telling or showing the computer how to do something. It's more of a Direct Manipulation interface: The user grabs things, moves them around, invokes methods on them, and things happen right then and there. In Visual Programming, you're describing how to do something later. -- Jeff Grigg


Alistair Cockburn's Hexagonal Architecture is a much more general concept. The Naked Objects Framework is different in that it largely collapses the user interface and database/persistence layer into the business layer, rather than pursuing a generic abstraction.



How can we separate the from the from the ?

I, for one, have been confused, thinking for some months that "Naked Objects" was the general concept that simple CRUD (Create Read Update Delete) screens could be auto-generated from business objects, and so I entirely missed the more important aspects of the Naked Objects toolkit at www.nakedobjects.org How could we make the Naked Objects toolkit more visible? Should we have this page be for the generic concept, and move the framework/toolkit content to Naked Objects Toolkit?

Others of us may have "entirely missed the more important aspects", too -- so how about some hints? -- Doug Merritt''

For some time, every time I saw mention of "Naked Objects", I said, "Oh; I know what that is. It's 'exposing attributes and methods directly through the user interface.' In other words, it's 'Auto Gen Crud Screens' for routine maintenance, and then you'll tweak the presentation of these screens, to match your desired application / web site style, add a few custom screens to handle special cases, and there you have it -- a typical, conventional application, done more quickly than usual.'" I missed the boat. I didn't really understand how an application built with The Naked Objects Framework is different from auto-generation of conventional CRUD (Create Read Update Delete) screens.

The Naked Objects Framework provides a useful graphical metaphor for doing Direct Manipulation of objects for (most) routine CRUD (Create Read Update Delete) maintenance tasks.


See original on c2.com