Archive for the 'Naked Objects' Category

The Scimpi Framework

Posted May 8, 2008 * Comments(2)

We have spent the last few months creating a new web development framework, which we have called Scimpi - see http://www.scimpi.org. No doubt your immediate thought will be: surely there are too many web frameworks already, why create another one? Well, unlike a project rationalisation I saw today on SourceForge, it was not because I wanted to brush up on my coding. We wrote it because Naked Objects is currently ignoring the biggest development area going; that of web applications. What Naked Objects currently offers is a unique choice of generic user interfaces that give the user complete, yet controlled, access to a complex domain model. What can’t be done with the framework is to create an interface that is more ’scripted’, that guides the user through specific tasks. While the generic user interfaces are ideal for the problem solver working within a complicated domain, they are not optimal for the typical process follower working within a simpler domain, or when working on small isolated task within a larger, more complex, system. For the latter type there tend to fewer options to offer and fewer possibilities to cater for. Therefore, such an interface will tend to be more prescriptive, but obviously there is some overlap between the two categories. While the generic interface involves absolutely no work to make it available, using a conventional web application framework to create a browser based user interface, however, requires an inordinate amount of work by comparison. Typically it would require the writing of controller and bean classes, crafting of JSP pages that access those beans and writing configuration files to tie these things together. Not only that, but there are also things like validation, security and internationalisation to be considered. Doing all this seems too much like hard work, particularly when you can already do everything that the domain model permits through the generic interface that magically appeared when simply exploring the domain model.

To make web application development simple there should only be one file per page, and each page should only detail what is absolutely necessary, keeping them short yet readable. For example, if I want to show an object then I should not need to work through each field laying out labels and content; simple markup that says ’show object x’ should be all that is needed. Hence Scimpi was designed to process HTML pages with additional markup that dynamically generates HTML snippets to include with the static markup. Each dynamic tag interacts with the Naked Objects framework and generates suitable markup to allow tasks like displaying and editing objects, running actions, building tables etc., to quickly build up dynamic web pages. There are controllers within the system and others can be added, but these are specialised devices, rather than a mandatory part of process. Also, as there are no new controllers to be written and the only interactions are defined within the the HMTL markup, there is no need for any configuration files, which just link together those disparate parts. This may seem at odds with the contemporary web application development process, but in reality all you are doing in defining Scimpi pages is detailing how your users will interact with the system, and this is no different than directing a user in exactly how to the use the generic user interface to complete a task.

In creating this framework we specifically chose not to use JSP as the mechanism to create the pages as these allow, and potentially encourage, code to be included. Scimpi pages need no code, they rely solely on the behaviour provided within the domain model. The pages are therefore simply HTML pages with additional markup.

Just to show how simple the process is here are a couple of example pages.

File 1: example1.shtml

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="style/screen.css"/>
  </head>
  <body>
    <swf:run-action object="service:claims" method="allClaims"/>
    <swf:table/>
  </body>
</html>

Screen shot 1: a table generated from the results of the allClaims method

Scimpi example 1

File 2: example2.shtml

<html>
  <head>
    <link rel="stylesheet" type="text/css" href="style/screen.css"/>
  </head>
  <body>
    <swf:run-action object="service:claims" method="findClaims">
      <swf:parameter number="1" value="city"/>
    </swf:run-action>

    <swf:short-form/>
  </body>
</html>





Screen shot 2: a form generated from an findClaims action with an included parameter


Scimple example 2


File 3: example3.shtml


<html>
  <head>
    <link rel="stylesheet" type="text/css" href="style/screen.css"/>
  </head>
  <body>
    <swf:action-form object="service:claims" method="findClaims"/>
  </body>
</html>





Screen shot 3: an entry form for running the same findClaims action, where the parameter is now prompted for


Scimpi example 3


I now have to start looking at other things, but the first release is going to be made available on SourceForge shortly.  For the moment the documentation and framework can be downloaded from the Scimpi website. (See http://scimpi.org/downloads/index.shtml for both addresses.)



    

    
  

    

    
 
      Aspects of Domain Model Management       

    

      Posted January 10, 2008 * Comments(0)       

    

      
For those interested in Domain Driven Design, there is an interesting article on InfoQ, by Mats Helander:  Aspects of Domain Model Management.  In the resulting discussion, Dan Haywood has made a couple of useful postings concerning the Naked Objects approach to dealing with the issues raised.


Richard



    

    
  

    

    
 
      Requirements-dominated vs. engineering-dominated projects       

    

      Posted November 23, 2007 * Comments(0)       

    

      
I have argued for some while that it is possible to divide business systems development projects into two distinct categories: ‘requirements-dominated projects’ and ‘engineering-dominated projects’.  One way to understand which of the two types you are dealing with, is to try to imagine that project failing, and then to write down a list of the 5 most likely reasons why that particular project had failed.  If that list looks something like:


    

  • The customers didn’t really know what they wanted
    • 

  • We misunderstood the requirements
    • 

  • By the time the system is delivered the requirements had changed
    • 

  • We did what we were asked but the customer didn’t like the result
    • 

  • The users said the system was unusable
    • 



then you are dealing with a requirements-dominated project.  If, on the other hand, your list looks something like this: 


    

  • Response times were too slow
    • 

  • The system did not meet the targets for reliability / availability
    • 

  • The system was not secure enough
    • 

  • There was a problem procuring certain components
    • 

  • The system didn’t work in the intended environment
    • 



then you are looking at an engineering-dominated project.  Of course any business system development project could fail for any of those reasons, which is why I stressed the need to consider  the ‘most likely’ risks for a particular project.  In today’s world, any system that has inadequate security, or reliability, or performance, is going to be a failure, but for many types of business system, addressing those issues is now comparatively straightforward.  Conversely, any type of system that has an unusable user interface will be a failure:  but if your business system has only simple functionality then it’s a straightforward matter to mitigate this risk. The ‘so-what’ from this two-fold characterisation is that requirements-dominated projects are the ones that demand agile development. Engineering-dominated projects don’t: in fact they’re better off run using conventional ‘waterfall’ methodologies.  Don’t get me wrong: there isn’t a software project on the planet that couldn’t benefit from at least one of the practices being promulgated under the banner of agile development.  But many of those practices are just the embodiment of modern common sense. 




I am talking about the core, definitional, practices within agile development:  highly-iterative development, small releases, continuous capture and prioritisation of requirements, intense customer involvement.  These practices are the only way you can succeed in the development of any requirements-dominated project.  Attempting to work in the old-fashioned way of trying to lock-down a specification up front is doomed to failure.  Conversely, though, creating a tight specification up-front is precisely what you should do for an engineering-dominated project.




Needless to say, I think, Naked Objects has the most to contribute to requirements-dominated projects.




Richard



    

    
  

    

    
 
      Workflow: A Triumph of Hope over Experience       

    

      Posted November 19, 2007 * Comments(10)       

    

      
In response a previous blog entry, Gerald Loeffler raised a question about the potential relationship of Naked Objects to workflow or business process management (BPM). 


I have always disliked both of those concepts for three reasons. The first is from technical perspective: they tend to encourage the separation of procedure from data and thus discourage good object-oriented design. The second is from a human perspectice: workflow and BPM systems tend to encourage a management philosophy that disempowers the users. I wrote about this in the original Naked Objects book back in 2002 and subsequently in my thesis.The third reason is that workflow, as generally conceived, simply doesn’t work! Recently I met with a workflow expert who works for one of the major systems integrators; to my susprise and delight he concurred with my assessment. He told me that in a very high proportion of systems that they install, the workflow element is completely switched off within a few months of the system going live. I asked him why his company continued to build workflow into new systems and he told me that it was invariably because the client’s management insisted upon it.What I mean by ’as generally conceived’ is building explicit representations of complex business processes or flows of work, and then running these scripts on some kind of engine that drives the tasks that individual users perform. This idea appeals hugely to management for two reasons: it allows the script to easily edited as the business organisation changes; and it gives the management better control and information about what is going on. In theory, that is. In practice this breaks down because real business processes are seldom capable of being 100% scripted, and as soon as you allow any kind of non-scripted variants the whole system breaks down. In The Social Life of Information (an excellent book), John Seeley Brown points out that the most valuable people in an organisation are those who’ve worked out how to get the job done for the customer, by overcoming the constraints of the formal business processes.However, I believe that there is a legitimate role for work assignment. Indeed I have designed several Naked Objects applications that involve a Task object. When the user logs on, they are presented with a ‘work list’ or ‘task list’. Each Task typically has a TaskType, a longer description and/or instructions, and, optionally, a Task Subject - the domain object (such as a Customer or Order), if one exists, that would be the starting point for the user to perform the task. Tasks may be assigned to an individual user or a team, and they may be transferred from one user or team to another. When the user has completed the task, they invoke the ‘Completed’ action on that Task, which records the date/time of completion, possibly one or more ‘completion options’ to record how it was completed, and then removes the Task from the worklist.


Sounds like worklow! So how does this differ from the approach I have just criticised? The distinction lies in what generates the Task. In the systems I have designed Tasks may only be generated by:


1. An explicit externally-generated event, such as the receipt of an email, or the scanning of an incoming paper document. The system can use this to generate a Task to deal with that event, and assign it to the appropriate team or individual - either based on a generic rule or on, say, the bar-coding on a scanned form. This, very limited, form of work assignment is indisputably an aid to productivity.


2. A user may generate a Task if they identify the need for an action that they cannot fulfill themselves there and then. In other words they can create a Task and assign it to a colleague, in which case the Task is acting rather like a structured email. Or they can create a Task to prompt themselves at a future point: e.g. bring [this object] back to my attention in 21 days, if nothing else has happened on it.


What these two design principles explicitly disallow is the idea that upon completing Task A, the workflow engine regains control and then issues Task B, either to the same user or another: the conventional notion of workflow. Rather, these two design principles reflect the fact that real business processes reside in the heads of the staff, and that is the best place for them.


So how do you stop things from falling between the cracks i.e. the user completes the first Task and then doesn’t continue to process a particular case? If this is a concern (and it need not necessarily be) one option is that all ‘purposeful’ objects (such as Case, or Order, or Enquiry) will have a status, such as ‘Active’ or ‘Completed’. It is a simple matter to run a periodic exception report, looking for all purposeful objects that have an active status (i.e. they should be being processed) and that do not currently have an associated Task that is assigned to someone, or have not had one for, say 24 hours. These can then be brought to a manager’s attention. Alternatively, the system could automatically send a reminder to the last person who marked a Task on that object as completed, asking them why they did not either create another Task, or move the purposeful object itself to a completed status. In my experience these situations do arise when the system is first used, but quickly die down once users get comfortable with the system.


I understand that all of this is a somewhat controversial view of business, but it is based on real experience. It reflects a very strong personal viewpoint that, to the extent that an information system involves human users, then the system should be designed to be the servant of the user, not the master. Most workflow systems attempt to be the master of the user.





    

    
  

    

    
 
      User interfaces: the enemy of Domain Driven Design       

    

      Posted October 25, 2007 * Comments(10)       

    

      
I’m passionate about Domain Driven Design (DDD).  Like many experienced object modellers, I was practicing this long before Eric Evans coined that specific term, though I have sinced learned some useful  specific patterns from his book. To me, DDD is about two things: focussing on the business functionality rather than on the technical implementation; and focussing on building a good model of the business domain rather than  just on the specific immediate requirements.  Like many others, I perceived that the key to this was to model the domain as behaviourally-complete domain objects: to actively resist the tendency to separate business functionality from the persistent domain entities.


Over the years I’ve been involved in a number of significant projects where the team started out with the intention of doing what we now call DDD.  I’ve seen some very good examples of object modelling, often just done on paper, sometimes even implemented as code.  But what is both striking and depressing is to observe how much the initial domain model has been eroded and/or corrupted by the time the first application is delivered.  Thereafter it’s a vicious circle:  the emasculated domain model delivers less and less of the required functionality, so more and more is built into layers on top of the model, and so on.  I’ve often heard the remark this this shows that a religiously-pure approach to object modelling just doesn’t work in the real world of business.  I never bought that argument.


The research that led to the naked objects pattern was motivated, in large part, by this sad state of affairs.  The naked objects pattern arose from the realisation that it was possible to convert this vicious circle into a virtuous circle:


If you are committed to designing behaviourally-complete domain objects, then the user interface need be nothing more than a direct reflection of the domain objects.  And if you make your user interface a direct reflection of the domain objects, then it will both force and help you to make the domain objects behaviourally-complete.


I’ve many times written about the DSFA in Ireland, which is not only a poster-case for Naked Objects, but also one of the largest-scale examples of ‘pure’ DDD anywhere in the world.  How do I defend that claim?  Because if you talk to anyone at the DSFA who has any involvement in the new generation of systems, whether they are a user, a business sponsor, or from the Information Services Division, all they talk about is the domain model: what are the capabilities of the Customer object? How does the Payment object relate to the Entitlement objects?  Should a (payment) Book object know the BookRenewalCycle object that it falls within? This is not just because the domain model is visible and concrete, but because there is nothing else (in terms of business functionality) to talk about.  The domain model has survived right through to implementation.  As the DSFA now discusses the next phase of business solutions to be created within the new architecture, the language of the discussion is how to extend the domain model, not how to write new ‘applications’.


I’ve also many times said that it is possible to use Naked Objects to help you explore your domain model, even if your ultimate iwhat ntention is to deploy that domain model within a more conventional architecture. But I now feel the need to put a caveat in there: one based on real experience.  Yes, you can use Naked Objects to help you explore and prototype your domain model as a set of POJOs, and I believe you’ll end up with a better domain model than by trying to do it using UML diagrams on any other modelling methodology.  But, be warned, as soon as you then concede the idea of designing a user interface to sit on top of the domain model, and you will find the domain model starts to degrade.   Users no longer talk about the domain ‘objects’, they talk about ’screens’ instead.  The screens then start to acquire attributes from multiple objects, and the behaviours start to get associated with the screens rather than the objects, and before you know it the domain model is little better than a logical data model (or even a physical data model!). 


People often say to me:  ‘Doesn’t this just reflect the reality that users need to see views that cut across the domain objects?’  No.  At the DSFA we built huge applications using hundreds of domain classes all representing persistent entities.  I can think of only two instances in the whole system where we created domain object classes (containing some business logic) that were not persisted and, it could be argued, really represented either a view that spanned multiple objects, or a high-volume entry form that fed multiple objects.  The belief that views should be independent of objects is just a self-fulfilling prophecy.


I’ve suggested in the title, user interfaces can be the enemy of domain driven design, and doubtless for this I shall get castigated for pushing idea that favours systems developers at the expense of the user.  The usuability community has never liked the idea of Naked Objects.  They’ve been quick to point out the many small usability issues with the auto-generated Naked Objects user interfaces.  But, to use a biblical metaphor, I suggest that they are ‘choking on a gnat while swallowing a camel’. Yes there are hundreds of small ways in which the Naked Objects user interfaces can and should be improved.  But there are many higher-levelways in which those same user interfaces are actually more usable than many hand-crafted interfaces I’ve seen from so-called usability experts:  less modal, more empowering, and with a real sense of Norman et al called ‘direct engagement’.


My challenge to the usability community is to stop fighting the idea of generic user interfaces, and apply what they know to building better ones.


Richard Pawson



    

    
  

    

    
 
      Naked Objects and AOP  -  Part 2       

    

      Posted October 19, 2007 * Comments(3)       

    

      
Last month I wrote about the potential synergy between Naked Objects and AOP.  Since then I’ve conducted my first crude experiments with Aspect and the AJDT plug-in for Eclipse.  (I found the latter remarkably straightforward to install and use).


 The first of my suggested uses for AOP within Naked Objects was to eliminate the need for adding resolve() and objectChanged() calls within your properties.  I managed to get this working, and I’ve posted the code below for anyone who’d like to try it out.


 (As I’ve made clear, I’m a complete beginner at AOP, so if anyone more experienced in that technology can see anything wrong with this code, or any improvements, please do post a comment.)


Richard




import org.aspectj.lang.reflect.MethodSignature;


import org.nakedobjects.applib.DomainObjectContainer;


 


public aspect ResolveAndObjectChanged {


 


// {{ Define the ContainerAwareObject interface and its methods




 


public interface ContainerAwareObject {}


 


private void ContainerAwareObject.objectChanged() {    container.objectChanged(this);


}


 


private void ContainerAwareObject.resolve(Object object) {


    container.resolve(object);


}


 


private DomainObjectContainer ContainerAwareObject.container;


 


// Naked Objects will inject a DomainObjectContainer here


public void ContainerAwareObject.setContainer(


    DomainObjectContainer container) {


    this.container = container;


}


// }}




 


// {{ Declare domain classes that should implement ContainerAwareObject


declare parents : projectname.dom.* implements ContainerAwareObject;


// }}




 


// {{ Define the objectChanged pointcut and advice


pointcut objectChanged(ContainerAwareObject target, Object objectBeingSet):execution(void ContainerAwareObject+.set*(..)) && target(target) && args(objectBeingSet);


 


after(ContainerAwareObject target, Object objectBeingSet): objectChanged(target, objectBeingSet) {


    if (objectBeingSet instanceof DomainObjectContainer) {


        return; // Don’t call objectChanged() within setContainer() method;




    }


    target.objectChanged();


    System.out.println(“objectChanged() called.”);


}


// }}




 


// {{ Define the resolve pointcut and advice


pointcut resolve(ContainerAwareObject target): execution(* ContainerAwareObject+.get*()) && target(target);


 


before(ContainerAwareObject target): resolve(target) {


 


    /*


    * This implementation assumes that the convention has been followed


    * that getters and setters have the same name as the private variable.


    * The following code determines the private variable name from the


    * getter/setter.


*/


    try {        MethodSignature ms = ((MethodSignature) thisJoinPointStaticPart.getSignature());


        String propertyName = ms.getName().substring(3);


        String variableName = propertyName.substring(0, 1).toLowerCase() + propertyName.substring(1, propertyName.length());


 


        Class targetClass = target.getClass();


        Object var = targetClass.getDeclaredField(variableName);


        target.resolve(var);


        System.out.println(var + ” resolved.”);


 


    } catch (NoSuchFieldException e) {


        // TODO Auto-generated catch block




        e.printStackTrace();


    }


}


// }}


}





    

    
  

    

    
 
      Lego, DSLs and Naked Objects       

    

      Posted September 29, 2007 * Comments(0)       

    

      
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



    

    
  

    

    
 
      Naked Objects and AOP       

    

      Posted September 17, 2007 * Comments(0)       

    

      
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.