>> --- John Carter <[EMAIL PROTECTED]> wrote: >>> Years ago, before the name Naked Object was even coined, >>> I constructed a naked object interface. >>> It failed. >>> Dismally. >>> I mean, I personally used it to tweak things, but my >>> users uniformly hated it.
In the late '80s I worked on several highly productive teams producing small business systems using a very powerful CASE tool. The CASE tool did a good job of producing basic CRUD (Create, Read, Update and Delete) screens for physical objects (relational tables, actually) -- including both simple and header-detail maintenance screens. Typically a moderate amount of "dressing up," in terms of selecting which data to include and exclude, improving the labels, and improving the layout to make it more intuitive, were done on each screen. I think the CASE-tool-generated screens could be considered a very primitive precursor to the use of full naked objects concepts. One could do similar things (and better) with objects, and a small amount of data-driven mapping code. Here's what we found: 1. On typical business systems, CASE tool generated screens satisfied the needs for editing 80% to 90% of the business objects (tables). The remaining screens were complex, custom and hand-coded. Still, this approach saved the projects *LOTS* of time and money. 2. The users were never really happy with the screens. What they wanted was 100% custom coded screens. But they wanted custom screens at the same time and dollar cost as the generated screens. This is quite impossible to accomplish. 2a. Also, the users wanted screens that showed and allowed editing of just about everything that could be relevant all at once. These screens were costly to run -- and this turned out to be a major contributor to the complete failure of one of the projects. So we concluded: 1. Do the bulk of routine maintenance with simplistic generated screens. 2. Write custom screens for the most critical and most frequently used functions. >>> [...] >>> Thought 2... >>> That Naked Object system [...] exposed the internal >>> representation of the object. In that case it was >>> water level in a cell measured in meters. The users >>> cared not a fig for water level. They thought in >>> terms of volume (m^3), an a very complex routine >>> mapped between the two. I like the "decorator" wrapping concept. --- "jhrothjr" <[EMAIL PROTECTED]> wrote: > [begin extract] > [...] specific organizational practices that tend to force > the separation of procedure and data even where the > software designer wants to adopt a more pure object-oriented > approach. We have identified five such practices: > > [1] Business process orientation > [2] Task-optimised user interfaces > [3] Use-case driven methodologies There's a big difference between "generic maintenance" and "task- optimized" design for user interfaces. I've seen a lot of this, and it often appears that people don't realize the difference. Two common failures that I've seen: 1. Some people push for a completely task-optimized user interface: Handling of exceptional and non-routine patterns of usage is ignored, and may be impossible. 2. Some people focus on generic maintenance: Performance of routine day-to-day tasks may be difficult, time-consuming and error prone. I see a lot of value to each of these approaches -- as long as they're not done to excess. > [4] The Model-View-Controller pattern > [5] Component-based software development. I believe that if MVC is "done properly," it should end up with a good domain model that, for the most part, could be mapped directly and usefully in a naked objects style. (But history has shown that arguments stating "If they'd only done it 'properly'..." can be /very/ weak. ;-) > To say this is a controversial list is to put it mildly. [...] > [end extract] > The web site is here: http://www.nakedobjects.org/ > and the book is online here: > http://www.nakedobjects.org/content.html To Post a message, send it to: [EMAIL PROTECTED] To Unsubscribe, send a blank message to: [EMAIL PROTECTED] ad-free courtesy of objectmentor.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/extremeprogramming/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
