Naked Objects is an architectural pattern and a framework for developing applications where domain objects takes a central role. Domain objects in Naked Objects applications form the core of the user interface, and are the focus of development efforts. Naked Objects recently released version 3.0 with support for Java 1.5, injection, an alternate UI, Hibernate object store, integrated security and contributed actions. Meanwhile, the ongoing efforts with the Irish Department of Social and Family Affairs, continue to provide a valuable case study in the use of Naked Objects. InfoQ took the opportunity to speak with Richard Pawson, the co-founder of the Naked Objects group and inventor of the Naked Objects pattern.
The Naked Objects pattern encourages the developer to focus on supplying a rich domain model with both data and behaviour, and supplies a view layer and a thin controller layer automatically:
Naked Objects stems from realising the following virtuous circle:
If you are committed to designing behaviourally-complete domain objects, then giving the users a direct view of those objects, and access to their methods, is all the user interface that you need - and this could be done automatically using reflection. And if you make your user interface a direct reflection of the domain objects, then this will both force and help you to make the domain objects behaviourally-complete.
This focus on the domain model draws some parallels to Domain-Driven Design:
I think they are very complementary. It was a belief in what is now known as DDD that drove me to conceive Naked Objects in the late '90s. We make use of several of those patterns in Naked Objects.
I honestly believe that anyone who is committed to the idea of DDD should be using Naked Objects, because it makes the benefits of DDD so much more concrete and visible. It also makes it easier to engage the business in the process. I have found from much experience over the years that you can't engage business sponsors in discussions of UML diagrams. This is why people resort to designing systems around screen wireframes (a very bad idea) — because it is easy to engage people in screen layout discussions! Prototyping your domain model in Naked Objects makes it just as easy to engage the business, but what they are actually engaging with is the domain model directly.
Secondly, I believe that Naked Objects and DDD are synergistic because it prevents the power of the domain model being unpicked by a hand-crafted V&C layer on top. My most recent blog is on this subject.
Expanding on how Naked Objecs helps you explore the domain:
What we're learning as we build more and more using NO is that the generic nature of the UI forces you to put stuff into the domain model that might otherwise have been omitted. The model is therefore a much more complete representation of reality - anything but inadequate or inelegant. The NO approach also clarifies concepts for the business themselves. My favourite example is that of "pre-payments" and "post-payments". This was mentioned in the original tender document, and informally it's clear what it means: a payment that hasn't been paid, and one that has. But the question we asked was: what generates these pre-payments to which the answer came back: it's what the customer is entitled to (as a result of receiving their pension). Eventually we were able to rename "pre-payments" as Entitlements, and "post-payments" basically became just Payments. Entitlements are pre-calculated (and may change retrospectively), while Payments are there to pay-off Entitlements when they become due.
However, Naked Objects may not be suitable for every application, and in particular, Richard cautions about its use for consumer applications:
Applications delivered using Naked Objects are suitable for internal use only: not for public access. We have never claimed that the resulting user interface is 'intuitive' - actually, research clearly shows that there is no such thing as an intuitive user interface, only a familiar one - there is a definite learning curve involved. But our aim has always been to deliver user interfaces that treat users 'as problem-solvers not merely process-followers'.
Naked Objects 3.0
Naked Objects 3.0 supports adding Java 1.5 annotations directly to the domain class in order to add declarative validations as well as field ordering, injection of shared services into the domain model, HTML and rich client interfaces (with more to come, potentially Eclipse RCP, command-line, and AJAX), integration with Hibernate to provide storage for the domain model, a built-in security model (which can be stored and administered in the database, a flat file, or in LDAP), contributed actions and a move to the Apache license.
Contributed actions allow services to contribute actions to the domain model, such that they become part of the user interface. This runs the risk of encouraging developers to pull behaviour out of the domain class and into a service layer:
We recently did a short project for a large client that claimed that it had already designed (but not implemented) their architecture along 'SOA' lines, with all the behaviour in services. We were able to use Naked Objects to build a very rapid prototype of their model, defining purely anemic entities and then having the services contribute all the actions. We absolutely would not recommend this as a design paradigm, but it was a question of working with what they'd done or not at all. However, as a result of this we were able to show them that their own conception of services was very poor and hugely inconsistent and, of course, we argued that had they started with the idea of trying to push as much behaviour onto the domain objects as possible then they would have done a better job of it.
Our view is that you should only use contributed actions where you have a behaviour that you want implemented across multiple types of object that can't inherit it. It is effectively a way to overcome the limitation of single-inheritance. Contributed actions are very like AOP, except that they happen at run-time not compile time.
It's possible to combine aspect-oriented programming with naked objects, as the Naked Objects blog has explored. The switch from the GPL to the Apache license was in response to users:
There are quite a lot of people don't want to work with a GPL product, unfortunately. Also, it was becoming a bit of an issue for us ensuring that the license was compatible with all the various other open-source libraries that we make use of within Naked Objects.
On the subject of the adoption of Naked Objects:
We had a very good reaction to the launch of Naked Objects 3.0 (a thousand downloads in the first week) - which is the first implementation of Naked Objects that we consider to be a complete viable platform. And we have a mailing list of several hundred people who have asked to be notified of new releases. But (leaving aside the startling exception of DSFA) I would have to say that it's still a fledging technology. Most people are probably using it as a prototyping tool rather than a full deployment platform. We hope that the coming months will see its use grow substantially.
I get the strong sense that a number of other technologies are approaching the Naked Objects concept gradually (Ruby on Rails, Spring ROO etc). We went straight for what we see to be the logical end point of those trends. For that reason Naked Objects is often seen as too radical (or opinionated) for mainstream development. Perhaps so, but we've seen what it can do for real, and we're not going back!
Richard Pawson expands on his comparison of Naked Objects with Ruby on Rails and Grails on his blog.
Naked Objects & the Irish DSFA
The Irish Department of Social and Family Affairs (DSFA) is the most visible example of Naked Objects in action. The first pilot project betwen the DSFA and Naked Objects went live in 2002, the work continued through a contract with the Naked Objects group in 2004 and as of September 2007, the applications are in "continuous use by more than 700 users." Finally:
In May 2007 the DSFA announced a new four-year programme to further extend the new architecture, develop a range of brand new applications, and migrate more of its existing legacy systems onto the new platform. It is expected that during this period the number of users accessing applications via Naked Objects will rise to several thousand.
Although Richard Pawson could not comment on the continued extension of the architecture, he promises that there is "more to come." As far as next steps:
Alternative auto-generated user interfaces. A new automated test framework. Development tooling. But I don't want to pre-announce.
On the basis of the DSFA project(s), the case study argues the following benefits: agility, prototyping and re-use.
Expanding on the subject of code-reuse:
There are two reasons for this. The first is simply that Naked Objects encourages good object modelling (behaviourally-rich entities, lots of polymorphism) and good object modelling makes for better re-use. The second reason is that when you re-use domain objects between applications within a Naked Objects environment, you don't have to worry about the UI. In a traditional architecture if you wanted to re-use, say, a Customer object, you'd either then have to write new Views and Controllers to use it, or you'd try to re-use the V&Cs from the previous application, only to find that those V&Cs were not solely relating to the Customer object anyway and would have to be picked apart.
But there's also a political factor. In my experience if you try to get multiple stakeholders in a room to agree on a common definition for Customer, say, it just doesn't work - they can't overcome the idea that each has their own specific requirements. But if you can show them something doing what they each want then its easy. The success of the Naked Objects project was all about being able to show the different stakeholders (not just tell them) how the common BOM could deliver what they each needed. Classical UML modelling just doesn't do that.
Further Reading
To learn more about Naked Objects, visit the official website, the wikipedia entry download the latest release, explore the Naked Objects Blog or continue reading more about Naked Objects on InfoQ.
Also consider reading about jMatter (a comparison of which was included in this discussion).