Naked Objects

I consider myself to be something of an expert on Lego.  In 1984 I wrote a book about robotics, which included instructions for building a number of quite sophisticated robots using Lego Technic.  The book never sold well, and is now long out of print  -  but it did make my (substantial) Lego purchases tax deductable!  Lego has oft been used as a metaphor for componentised software.  I think it’s a poor metaphor, except insofar as it exposes the woolly thinking that surrounds the idea of software componentisation generally.  A componentised system is one in which it is possible to replace a component with another implementation that conforms to the same specification:  thereby not only giving you the choice of alternative suppliers, but also to encourage innovation.  Sound and video systems, desktop PCs, and bicycles are examples of strongly componentised architectures.  Software is increasingly componentised thanks to the growth of strongly defined interfaces, from public standards to Spring beans. (Note: although objects and services can perform the role of components, generally they do not:  objects, components and services are in fact three complementary but quite distinct ideas  -  the subject for a future blog.) Lego is not a componentised architecture.  With the exception of different-coloured bricks there are few opportunities to swap one Lego piece for another that confirms to the same spec but that offers certain advantages.  There are even less opportunity to swap a Lego piece for one from a different manufacturer.  (Trivia:  the most patented part of a Lego brick is not the knobs on the top, but the underside of the brick).   

One could possibly hold up Lego as a metaphor for a rich plug-in architecture such as Eclipse, where new ‘pieces’ can be plugged into almost any point on the existing system due to a single comprehensive joining mechanism.  But there are few examples of such well defined plug-in software architectures, and the metaphor doesn’t really enrich our understanding of them. However, I want to argue that Lego is a very good metaphor for another emerging trend in software development: the Domain Specific Language or DSL.  Lego, in common with music, crochet, and predicate calculus, is fundamentally a domain specific language. The domain is building small-scale (usually!) physical models, both visual and functional.   Within any given domain one can easily envision multiple languages, each with its advantages and disadvantages.  The book that I mentioned above, in fact had projects both for Lego Technic and for Fischertechnik, a German construction set, and leafing through it again for the first time in many years I see that I devoted a couple of pages to comparing the two for the specific application of building robots.  A useful way to compare two domain-specific languages is along two dimensions.  One dimension is applicability:  the range of different things that can be expressed in the language (within the domain boundaries that is).  The second is the parsimony of the language: which translates readily into productivity.   What prompted me to write this week’s blog was a conversation with Philip O’Donohoe at the DSFA in Ireland.   Philip reminded me that back in 1999 when I first started working with them, I had the whole of the management team playing with Lego in a workshop.  One of the assignments was to take a collection of varied Lego pieces and to lay them out on a large 2×2 grid representing the two axes described above.  The photo below shows one such example:  The horizontal axis is the breadth of applicability; the vertical axis is the parsimony or productivity gain.   So, bottom right you have the basic building blocks of Lego such as bricks, beams and plates; top left you have pieces that add a lot of value if you are building one very specific type of model, but that lack generality.  Bottom left you have the equivalent of what programmers call ‘cruft’  -   small pieces that have low applicability and low value-add.  The most valuable pieces, and the hardest to conceive and design are in the top right.  Over the last five years the DSFA has created its own ‘Common BOM’ (Business Object Model).  To use the most up to date parlence, their Common BOM is really a Domain Specific Language, and it is as good an example of a DSL as you will find anywhere in the world.  What makes it a good DSL, I believe, is that it is defined as a very pure object model.  Objects are not the only way to define a DSL, but I believe, passionately, that they are the best way  -  or at least the best way that is available to us as a practical proposition right now. The Common BOM has already proven its worth: perhaps the most striking example being when the 50,000 lines of code in the prior Child Benefit Administration system were replaced by a new system based on the Common BOM plus less than 1000 lines of bespoke application code.  The DSFA is not content to leave it there:  over the next four years they want to further improve it: to broaden its applicability (i.e. to support an even bigger set of business applications); and to make it more powerful (i.e. reduce the number of steps needed to create an application). To that end Philip was saying to me that they now want to go back and ‘do the Lego 2×2’ exercise on the Common BOM.  Lego is not in fact one DSL, but several.  It started as a DSL for building model houses; then in 1961 came the first wheel and the capability to model vehicles, followed by trains in the mid ‘60s; now there are Lego DSLs for pirates, space travel, and many more.  Each of these DSLs is defined by a set of pieces.  What makes all of them so effective, though, is the generic coupling mechanism (the famous Lego knobs) that makes it easy to use the language. The DSFA’s Common BOM is not dependent upon Naked Objects – having now been designed it could be deployed within a more conventional architecture  -  but the value that Naked Objects adds to the Common BOM is that it makes it  easy to use as a DSL.  The elements of the language (the objects themselves) are easy to get hold of and manipulate; turning them into a prototype does not involve gluing them together with user interface code; and the results are quite presentable, so that everyone can still clearly see the elements of the DSL in the finished product. 

I can’t wait to see the results of the DSFA’s 2×2 assessment. I’m off up to the attic now to drag the Lego set out again . . .

Richard Pawson

In the course of presenting Naked Objects to a new community this week, I was asked how it compared to the Ruby on Rails and/or Grails frameworks  -  a question that comes up quite frequently.

Naked Objects is similar to Ruby on Rails and Grails in the following ways:

• All three frameworks demonstrate a very high commitment to the principle of Don’t Repeat Yourself (DRY), specifically by deriving the presentation and/or the persistence layers from the domain model.
• All three frameworks favour convention over configuration as a programming model.
• All three frameworks can be used to deliver finished applications, but may also used to build prototypes of systems that will eventually be delivered on a different platform.

But there are also some profound differences.  The first difference is the intended application: both Ruby on Rails and Grails are explicitly positioned as frameworks for developing web-based applications, specifically web-based applications that have a significant dependence on structured data i.e. need to connect to a relational database. 

By contrast, although Naked Objects 3.0 does now offers a pure-HTML user interface as an optional alternative to the rich-client (’Drag and Drop’) user interface,  Naked Objects has never been positioned as a web-development framework.  The 100% auto-generated user interfaces (whether rich client or HTML) can both be highly effective user interfaces  -  but both of them require some familiarisation.  They are very well suited to applications for use inside an organisation (our experience at the Department of Social & Family Affairs in Ireland has proven this), but they are totally unsuited for applications to be used by the public on an occasional basis.  This is the distinction between what usability expert Alan Cooper  has called sovereign and transient applications.  (Of course there is nothing to stop you from developing a sovereign application using Naked Objects and then to design a more conventional user interface to access the same domain objects for a transient application).

Perhaps because of this difference in emphasis, there is also a profound architectural difference between Naked Objects and Ruby on Rails and Grails. The latter both embody the Model-View-Controller architectural pattern, with the result that much of the business logic in an application written for these frameworks ends up in the controllers.

 Naked Objects does not embody the Model-View-Controller pattern. With Naked Objects the application developer has neither the need, nor the opportunity, to write Controllers: all business behaviour must be encapsulated on the domain (Model) objects, and the framework generates the whole application from these. 

 (As an aside, when I completed my PhD thesis on the naked objects pattern in 2003, the university appointed Prof. Trygve Reenskaug from Oslo to be the external examinier.  Reenskaug isn’t a name known by many developers, but he invented the Model-View-Controller pattern.  To say that I was interested to see how he would react to the naked objects pattern is an understatement!  To my relief he really liked the thesis  - recommending that the PhD be awarded at the very start of my viva  -  and graciously said afterwards that he believed that the naked objects pattern was more faithful to original intent of MVC than the way that the latter had subsequently developed.  It was never his original intent that Controllers should end up incorporating business logic).

Thus, the fundamental difference between Naked Objects and Ruby on Rails or Grails is that Naked Objects requires an absolute commitment to ‘behaviourally-complete’ domain objects.  Both Ruby on Rails and Grails have often been described as ‘opinionated frameworks’, but the truth is that Naked Objects is even more opinionated than they, and we accept that that is bound to limit the size of the community who are willing to use Naked Objects. I make no apology for that. 

Ruby on Rails or Grails are both excellent frameworks  -  everyone I have met who uses them seems to love them.  They are easier for many developers to come to terms with than Naked Objects.  But, as I argued in the thesis, and we have clearly demonstrated in practice since, an application written in Naked Objects will achieve far higher levels both of re-use and of aglity (ease with which future changes to requirements can be accommodated) than one that separates business functionality between entities and controllers.

Last week I was involved in a teleconference with Ramnivas Laddad  -   a leading proponent of Aspect Oriented Programming and author of  the excellent book ‘AspectJ in Action’.  We were discussing (amongst other things) the potential synergy between Naked Objects and AOP.

We’ve been reluctant to tie Naked Objects specifically to AOP, because that might narrow the community to which it might appeal.  But it seems to me that for anyone who already understands and uses AOP (specifically AspectJ) then there are some very easy advantages to be gained. Three immediately sprang to mind:

1) Use an aspect to add the required resolve() and objectChanged() calls within properties at runtime.

2) In a Naked Objects application it is not safe to use a simple constructor within your code (e.g. Customer newCust = new Customer(); ) because then the application container does not know about the new instance and can’t look after its persistence automatically.  So you need to write something like:

 Customer newCust = (Customer) container.newTransientInstance(Customer.class);

 where ‘container’ refers to an injected instance of the application container, which Naked Objects can inject automatically.  Again, the need for this could easily be eliminated by an aspect that defines a point cut at instantiation. 

 3) In Naked Objects 3.0 a method (such as emailCustomer(String message)) may have a corresponding validateEmailCustomer(String message)  and/or disableEmailCustomer() method.  These will be called automatically by the framework to determine whether the user should be able to invoke the action.  However, these constraints are not automatically enforced if the emailCustomer() method is called programmatically i.e. from inside another action.

If you do not trust programmers to invoke your domain methods safely, then a good practice would be to call the validate.. and/or disable.. methods from inside the emailCustomer() method and throw an exception if any of them failed their tests.

Using an aspect, this capability could be added automatically.

Incidentally, we are often asked why Naked Objects requires the validation and/or disablement rules to be extracted into separate methods  -  why not just write them inside the emailCustomer() method and throw an exception if they fail, trapping the exception to present a message to the user.  Well there are two reasons.  The first is that we believe that you should only use an exception to handle a situation that ought not to occur, such as a technical failure or a programming error.  Whereas a user attempting to invoke a method without valid parameters) is something that can and will occur often.

 Secondly, and more importantly, if the rule was enforced only inside the method, then it would not be possible to find out if the constraints have been met without attempting to invoke the method.  By separating out the logic, we are able, for example, to keep the ‘OK’ button on a dialog box greyed-out until the user has provided a valid set of parameters. 

The reason why some people find it hard to see this value,  is that in a conventionally-architected system, validation and availability rules are typically implemented within the Presentation and/or Controller layers,  and then many of the same rules are implemented all over again within the domain objects, and sometimes again within the database design.  We believe that that business logic should be implemented in one place only:  on the domain objects.  In Naked Objects, the rules for disabling a method, or validating the parameters, work whichever style of user interface you create from those domain objects.

 Personally, I’ve never yet written an Aspect  - something I intend to rectify in the next few weeks and try out these ideas.  (Or at least the first two  -  the last one looks a bit more tricky to program!).  But if there’s anyone out there who is already fluent in AspectJ and would like to try out the ideas first  -  let us know how you get on, and we’ll post it on this blog.