Naked Objects, Point - Counterpoint 2
The Pragmatic Programmer folks have a new book out called Domain-Driven Design Using Naked Objects which caught my attention. The title caught my attention, and I figured the author was using Naked Objects in the same vein as Jamie Oliver as “The Naked Chef” (old series on Food Network). Essentially, the ingredients are used to their full potential, complimenting each other without the heavy use of spice. So I decided to do some research on where this came from. My suspicions were confirmed, and made even more sense when I found the original thesis came from someone at Trinity College, Dublin.
I found the original thesis by Richard Pawson entitled Naked objects where he details the principles behind the concept. The thesis is very readable, as theses go. It is broken up into an introduction, a case study, guiding principles, etc. What I found more interesting was the forward written by the pioneer of the MVC pattern, Trygve Reenskaug. The concept of Naked Objects isn’t exactly new, and it should be lauded for its intent of getting back to the proper intent of object oriented design and programming. Of course, as a technology, and as some of the design constraints of naked objects, the thesis is not without detractors. For example a short paper by Larry Constantine called The Emperor Has No Clothes: Naked Objects Meet the Interface .
The true value in something like Naked Objects is to get you to adjust the way you are thinking. The main concept is to build the complete logic of the system using a finite set of domain objects. The framework is designed to take care of database persistence and user interface. According to the forward in the thesis, the spirit behind MVC is that each view is mapped to only one object, although each object might be mapped to many views. The controller is responsible for mapping the events of the view (inputs, etc.) to the domain model. Essentially the domain model (or model) uses views for output and controllers for input. This is different from the way it was originally described to me and I originally understood the pattern. Pawson argues that the framework can generate the user interface views and controllers automatically. Further advances in the concept also automatically maps the domain model to a relational database using Hibernate .
The software developer side of me likes this concept. It’s less plumbing to worry about. I don’t have to know how to code a user interface. I can get my work done quicker. However, the user interface design side of me loathes the concept because the user interface (admittedly by Pawson) is not easily grasped without training, nor is it particularly accessible. The architect in me is thinking about how I can have my cake and eat it too. Ignoring the problem of database mapping for a moment, the real challenge is in the view/controller (VC) layer. Pawson sites arguments from advocates of Object Oriented User Interface (OOUI) design that there is only one true correct way of representing an object. Yet turns around and presents two: an icon to represent the object and a dialog box to represent the content in the object. In my own project I am working on now, there are at least two representations of every object: the view in a list, and the view of the full content of the object. Nevertheless, there still remains concepts I can leverage.
In some respects Wicket would be an ideal candidate for dynamic generation of VC code. Or at the very least, due to its attempt to treat the view layer in an object oriented manner, some extensions to the application can dynamically generate the controller side. I have some reservations about pursuing that too far at the moment. The real conundrum is in the presentation layer. Managing information and behavior is something that object oriented languages are designed to handle. It is right and good to take advantage of the features of your language to properly model the business domain. However, representing that same information to the user in a way that makes sense to the user is a completely different discipline. I can argue against the principles in OOUI till I’m blue in the face, but that doesn’t solve the fundamental problem.
What we need is a way for the programmers to create the functionally complete object oriented domain model, while your user interface specialists concentrate on their responsibility. While frameworks such as Wicket have tried to address that very problem, it is my personal opinion that they fall a little short. I don’t think the fault lies with Wicket. The fault lies within the current set of W3C standards and differing levels of browser compliance. The W3C is still stuck on a model that prefers static information. If the W3C were to truly pursue a model where the user interface layer is bound to certain objects and the browser makes calls to the server to render these objects we might have a better solution. We’ve already started down this path with AJAX and the myriad of Javascript frameworks to make this work. Needless to say that there is a lot of future work that has to be done in order to truly see a synergy from functionally complete domain models and an object oriented user interfaces.
The goal of such an endeavor should be to allow user interface designers these freedoms:- Create the representations of the objects as they see fit
- Create the rules of how to select the correct view from the different possibilities.
The controller logic should be built into the browser already, in terms of invoking the domain model (or representations of a remote object).
While I’m on the subject of Naked Objects and domain models, I’d like to make a minor rant on Object/Relational Mapping tools. One of the problems is that ORM tools tend to require accessor and mutator methods (getters and setters) for every field that is going to be persisted to the database. While you are technically encapsulating the internal state of the object, in 99.44% of the cases there is no difference in using the accessor and mutator methods and directly accessing the underlying attributes of the class. In a properly designed object, you only need to expose information via accessors that the user is allowed to see, and you only provide mutator methods for what the user is allowed to change. ORM tools require you to violate those principles if you want to persist the information down to the database. Some ORM tools (ActiveRecord) generates these accessors and mutators dynamically for you. That’s great for convenience, but terrible for a properly designed domain model. For the time being, there really is no alternative unless you write the ORM layer yourself. Not recommended if you can help it.
Hi Berin,
Thanks for this post; as the author of the pragprog book, glad you’ve discovered Naked Objects and taken the time to dig into it. So I’d like to make a few points.
So, first thing is that since the thesis was written 5~6 years ago, Naked Objects has been deployed on a major system in Ireland for a government department; Richard and I were involved from the beginning on this project, and we both are part-time advisors. So we now have a lot more experience of Naked Objects “in the field”.
Per the UI not being particularly accessible, that doesn’t really seem to be a problem. The app is deployed to 600+ end-users, who generally have a good understanding of the domain. Being able to see the domain objects in the OOUI works well. It’s worth distinguishing (what Alan Cooper calls) sovereign applications vs transient applications. A sovereign app is one that is used every day - for me it would be Eclipse IDE, the UNIX shell, etc. A transient app is one used occasionally, like a flight check-in kiosk. The end-user here doesn’t care about the domain model, and here devices such as wizards are appropriate to guide the user through the app. NO works exceptionally well for internally-used enterprise apps, ie as a sovereign app.
Per multiple representations, I’ll leave Richard to argue the technicalities of whether an icon vs an edit view vs a view in a collection are different representations. Perhaps they are. It’s not a blocker for any end-user I’ve spoken with, though.
Interesting you mention Wicket. In my book one of the things I wanted to demonstrate was that a Naked Objects-developed domain model can be skinned with a custom UI. The technology I chose to demonstrate this was, in fact, Wicket. I’ve also been posting a series on this theme at my blog, http://danhaywood.com.
You say: “representing that same information to the user in a way that makes sense to the user is a completely different discipline.” I agree, though for many of the domain objects (80:20 rule?) don’t need tailoring. One way to think about this is in terms of problem spaces and solution spaces. Most of the time we can get by just representing the problem space (the “naked” domain objects). Where we have a high-volume use case that touches lots of domain objects then we introduce (what I call in the book) a transient “process object”. This lives in the solution space. Wizards are an example of this. However, allowing the user to always get to the underlying problem domain is what is key to the end-user flexibility (what Richard calls “operational agility”).
You said “The fault lies within the current set of W3C standards and differing levels of browser compliance”. Just to point out that NO is more than just the web, it is also client/server. Indeed, the Swing-like “drag-n-drop” viewer is much more flexible that the HTML viewer. That said, there’s nothing to stop GWT or JavaFX viewers from being developed; I do know of one GWT viewer that is in the works.
You talked about “allowing UI interface designers to .. create the representations of the objects as they see fit.” Agreed, this is our vision too. Already, Scimpi (http://scimpi.org) is a sister project to Naked Objects that does this for the web; it uses a naming convention it searches for the best view to represent the domain object (eg Customer.html, if it exists, otherwise generic.html). I am also working on a UI using Eclipse RCP; it uses the chain of responsibility to ask registered viewers if they can render a domain object. There’s a screenshot of this in the book.
To finish up; the way I see it the UI isn’t really the battleground. We can build (and are building) more sophisticated viewers that address your concerns. No, the battleground is the domain model. The reason I called my book “Domain Driven Design using Naked Objects” is because, in my view, NO is just a fantastic way of building complex domain models. Being able to view the domain objects so quickly creates a tight-feedback loop, allowing the developer and the domain expert to rapidly build a shared understanding of the domain (what we DDDers call the “ubiquitous language”). In enterprise apps the easy pickings have been had; with DDD we can tackle more complex undertakings.
So, I hope I’ve addressed some of your points and thanks again for the post.
Dan Haywood
It’s an honor to have you respond to my blog entry. I have to admit that there is a lot of good with the domain driven design approach. I don’t really find fault with having a behaviorally complete domain model. In fact, that was the true intention behind object oriented programming and I can appreciate something that really makes you think in that direction.
I’ve been designing and building software applications for the past 15+ years, and I’ve learned many things. I’ve worked on both the front end and the back end, and I’ve come to some of my own conclusions. I believe that Pawson and I can agree that the best user experience is one that enables a user to do more by removing unnecessary constraints. We both agree on the point that software that leads you by the hand like a child often gets in the way of solving the problems that the software is supposed to support.
Where my views differ from Pawson has to do more with where our experiences differ. A mental model of the domain is not all that a user needs to have a truly usable and intuitive user interface. Having the concept of a design metaphor is imperative to having a predictable user interface. Predictability is a key element of usability, but not the only element. The user needs to have a clear concept of how to navigate around the system, as well as a system that helps the user learn more about the way things work.
I personally believed that Pawson was too quick to surmise that his user interface was empowering in comparison to the previous system with Ireland’s government. The point being that the users went from a green screen text only mainframe application to a graphical user interface. Given the constraints of building a text only system, it’s no wonder that the government users felt more empowered. What was more interesting to me is that despite the major change of user interface, there were still some people who were not in violent agreement. In his research he never revisited this point again. I submit that the results of that part of his questionnaire may have been quite different if the old system were graphical.
In terms of having a behaviorally complete object model I believe we are in violent agreement. In terms of skinning the objects (for lack of a better term), I think we also can agree that will help bridge certain gaps. In terms of the default user interface, I think any responsible project owes themselves to include budget for user interface related tweaks.
If I had the time (which unfortunately I don’t) I would start down the path of bridging the gap. The bottom line is that a web based application provides certain benefits in terms of deployment, manageability, and support that a desktop based app does not have. I speak from experience deploying both models of applications. Yet, despite all the time available for browser based applications it is only recently that we are starting to see examples of teams paying attention to usability. Even still, accessibility lags behind.
I believe that all of these issues can be addressed. I also believe that the presentation layer (browser or otherwise) should be able to handle the details to maintain accessibility as we customize the user interface. Naked Objects looks to be a great tool, and the lesson it gives in terms of creating a functionally complete domain model is essential. I just prefer my objects to have some clothes on. That way the remainder of the users that can’t deal with the NO user interface aren’t left out in the cold. (writing this with nearly 2 feet of snow on my deck)