--- In [EMAIL PROTECTED], Luiz Esmiralha <[EMAIL PROTECTED]> wrote: > On Mon, 08 Nov 2004 17:37:49 +1300 (NZDT), 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. > > > > Today I stumbled across the notion again at > > http://www.nakedobjects.org > > > > and the thought collided in my mind with a quote from Bjarne > > Stroustrup: > > http://www.artima.com/intv/goldilocks3.html > > "My rule of thumb is that you should have a real class > > with an interface and a hidden representation if and only if you can > > consider an invariant for the class." > > > > So my first Thought for the Day on Naked Objects.... > > "Objects should never be so Naked as > > to be able to corrupt the invariant." > > ie. Not all methods and setters should be visible, only those > > invariant preserving public accessors. > > > > Thought 2... > > > > That Naked Object system I did all those many years ago 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. > > > > So my second Thought for the Day on Naked Objects.... > > If the internal representation differs painfully from the users > > external view on it, the Naked Object should by default dress itself > > up a little to present the users view. > > > > ie. Naked Objects Bad. Flimsily dressed objects with mostly see-through > > clothing and the occasional corset - Good. > > > > The Naked Objects implementation lets you choose which objects are > "naked" and doesnt expose the internals of an object to the user, only > the non-private interface. Properties are accessed though getters and > setters as usual and private methods cannot be called from the outside > world.
It's even a bit more restricted than that. There is a very specific protocol involving naming standards and required method signatures that you have to follow before either an object or any field or method on that object is visible to the outside. While I hate to use the word impossible, I can't think of a way offhand of accidentally exposing something to the outside world that you didn't want exposed. > The main idea behind this is permiting direct access to the underlying > domain model of your application and automatic generation of the GUI. In the book, they use the notion of "expressive objects", or "behaviorally complete objects". That is, you expose the domain objects that are natural to the way the customer thinks about the domain, and you then make those objects express ***all*** of the properties (fields and actions) that those natural objects can have in the user's conceptual model. > This way, you only have to worry about coding the domain logic and > building a very tight domain model. I'm not so sure I would go that far! However, the notion that the top layer of the domain model is a direct reflection of the user's intuitive domain model is very attractive. > I think its a beautiful idea and I used it to prototype a system with > great success. I would like to try and plug a custom GUI toolkit into > it. It's not just a wonderful prototyping tool. I've sometimes thought that all applications should be written that way, with task oriented interfaces bolted on top where there is a clear need. They've got their own test package built in. It's somewhat similar to FIT, but uses jUnit as the vehicle. One very nice thing is that it produces output that can then be dropped right into a training manual. It's a very controversial approach. Here's an extract from their overview: [begin extract] The continued separation of procedure and data could be ascribed primarily to inertia: that is how most people learned to design systems and they find it hard to think any other way. However, this individual inertia is usually reinforced by a number of 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: Business process orientation Task-optimised user interfaces Use-case driven methodologies The Model-View-Controller pattern Component-based software development. To say this is a controversial list is to put it mildly. Several if not all of these phenomena have the status of sacred cows within the systems development community. None of them can be dismissed as simply bad habits. All of them are conscious practices that either clearly deliver a benefit or have been designed to mitigate a known risk in the development process. We are not suggesting that any of these practices is 'bad'; merely that they have the side effect of discouraging the design of behaviourally-complete objects. [end extract] The web site is here: http://www.nakedobjects.org/ and the book is online here: http://www.nakedobjects.org/content.html John Roth > > Cheers, > Luiz Esmiralha 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/
