I’ve googled a bit, asked some questions on SO, and learned that the approach I proposed earlier has a name: Naked Objects pattern. There are several frameworks implementing the concept, most notably the Naked Objects framework, which is the most universal and “pure” implementation.
I’ve played a bit with this framework and was quite disappointed. As people answered on Stack Oveflow, people tried to implement some variety of NakedObjects-like framework, but none widely known because most of these attempts failed:
All attempts I have seen always end up with user interfaces that even the creator have problems liking. It also seems like there’s no amount of meta-data you can add that will make these UI’s nice. (answer by krosenvold)
And, in the case of Naked Objects framework this statement seems to hold true…
Naked Objects framework demo UI
Naked Objects framework demo UI
Naked Objects framework demo UI
First of all, I have absolutely no idea what to do. Finally it turned out that most operations are to be performed from context menus. And their context is sometimes strange. I think it may be rather nice framework, if you use it correctly, but the very approach to constructing the UI is rather outdated. People need rich, usable UIs, where they can do more work in less time.
I think today good implementation of Naked Objects is impossible, because computers are too stupid to be comparable with work of even not very good UI designer. And to emphasize,
computers are too stupid.
A program is created to solve a problem. A concrete problem, a set of problems, a wide class of problems. If the program is designed to aid in solving more than one problem, user must perform different sequences of actions to accomplish his task. Some actions are performed together more frequently, others are simply needed rarely. So, actions or commands are not created equal. And to construct a decent UI we must take into account all these differences. No amount of metadata is enough for a machine to layout nice UI. Well, some amount will be enough, but it will be amount of additional data exactly equal to those in manually designing the UI; in such case our framework would be useless.
Now we note, that this argument about layout is applicable only to graphical interfaces. In text-based, conversational UIs, like bash or BeanShell you don’t have to worry about one button sitting in inconvenient place — but you have to remember all commands. Command-line UIs are much more versatile, but sometimes too complex for the user…
Wait, if the complexity of command line is acceptable, why can’t we apply the Naked Objects pattern in constructing them? There’s really no reason, and everything is in fact already done! Take PowerShell or BeanShell. Just have domain-specific classes and operate them directly, in any way you want. Sometimes it’s good, but in most cases too complex. So you sit down for a couple more hours and write your own CLI. But we can use Naked Objects and autogenerate parser, help system, formatter, script support, whatever you want. I’ve made some steps in this direction in aforementioned Cliche library. It proved useful, I already use it in 3 small programs, and I’m satisfied. Based on this experience, I want to say that although the future of Naked Objects may be bright, today console interface is the single thing where it works really well.
