Naked Objects - a BOF session after the end of the normal day here. Naked Objects - oddball thing about the name - book lookup on Amazon yields some "interesting" nearby subjects
The idea - to get rid of all the extraneous things - reduce to the leanest, bare essentials. Four layers in classic architecture:
- Domain Object Model
Naked Objects eliminates the controller layer - encapsualtes all business functionality on the entity objects (note - this elides any issues with session access to behavior that is permission based). Make the presentation layer generic. Make the persistence layer generic. In theory, generate the presentation and persistence layers from the domain model. I detect MVC being reinvented in the Java sphere :)
An example - conference registration:
Noting that a delegate can be part of a company. The demo proceeded using Together/J to build the domain using UML (ed. - I am historically very wary of this kind of tool and development model. In particular, I find it easier and faster to just use a browser :) ). After building the four domain classes, a build yields a simple set of classes that have some basic UI behavior (not unlike a Smalltalk inspector, although less powerful than Trippy to be sure). Relationships? There's a visual programming way of doing that (like PARTS, noting that we've been there, and it doesn't scale...). Important note on that being that the Together/J linking behavior is not a necessary part of Naked Objects - it's a part of Together/J that is independent of what you are doing.
My main concern would be the assertion that we can make the UI generic. In my experience, lots of work ends up going into the UI that is only marginally related to the domain - ways that the UI can be configured by the end user (in BottomFeeder, for instance, the ability to zoom/unzoom different parts of the UI, and how that depends on the current UI state. I guess I just have a hard time with the notion of a generic UI. It flies in the face of what I've had to do with Bf.
Now a second session on ModelScope - a prototyping tool. The notion is model driven prototyping, using state transition diagrams. The tool interprets that to create the model. No code generation from the tool - it generates models. Events change the system, but may not be associated with a single object - thus the usage of state transition diagrams. No GUI for the front end, so things are loaded from a front end text file. They have an engine that generates models.
MODEL OT2004 OBJECT BOF NAME BOF Name ATTRIBUTES BOF Name String STATES proposed scheduled cancelled TRANSITION @new*Propose=proposed*Schedule=scheduled @any*Cancel=cancelled OBJECT Room NAME Room Room ATTRIBUTES Name Name String STATES available TRANSITION @new*Make Available=available available*Schedule=available EVENT Propose ATTRIBUTES BOF BOF BOF Name String EVENT Schedule ATTRIBUTES BOF BOF Room Room EVENT Cancel ATTRIBUTES BOF BOF EVENT Make Available ATTRIBUTES Room Room Room Name String
Then you run the model generator (ed. - Java based - wouldn't Smalltalk or Lisp be way, way easier for this sort of thing?). You get a model that allows you to work with the state transitions as they have been defined. Hard to tell much at this point - needs more fleshing out.