Naked Objects
From Richard Pawson:
Object-orientation was supposed to give us business systems that were much more agile, allowing organizations to enhance their day-to-day operational agility as well as their ability to make strategic adaptations to market changes....
Several of us involved in object-oriented design, however, have speculated that the reason these benefits have not been as substantial as promised, or as quickly realized, is that the principles of object-orientation were being diluted with traditional techniques and technologies.
Three years ago I set out to prove not only that a purer form of these principles would do a better job of fulfilling their original promise, but also that this could be a practical approach for commercial IS organizations. The result of this work is an approach called "naked objects."...
The naked objects approach requires a 1:1 correspondence between the business objects -- such as customer, product, and order -- that users manipulate on the screen and those in the middle tier of the architecture.
That is, business objects must show directly through to the user, instead of being "clothed" in the menus, scripts, and dialogue boxes of a conventional user interface.
Using the Naked Objects framework, the screen representation is automatically generated from the core business objects, without writing a single line of code for the user interface. All the programmer does is specify the business objects themselves: their attributes, their associations with other objects, and the business methods they can fulfill.
When the object definitions are compiled and run, a part of the toolkit known as the viewing mechanism automatically translates an object's specification into its screen representation. Individual objects show up as icons, which can be dragged and dropped, or "opened." This viewing mechanism is truly business agnostic.
With the Naked Objects framework, there is simply no way to provide the user with any functionality except as a behavior encapsulated into an object. When developing a system, designers would learn which behaviors to encapsulate into an object by asking questions such as, "What actions would you want to take with this object?" and "Where might you want to drop this object, and why?"
Business rules are written into the business objects themselves. If Object A cannot be dragged onto Object B, it will instantly flash red to indicate that the action is not permitted. Holding the cursor there for a moment longer will bring up an explanation of why it is not permissible. Right-clicking on an icon brings up a menu list of the actions the user can take.
Several of the actions may be grayed out, indicating that they are not permissible with the object in its current state. Again, holding the cursor on the menu for a moment will bring up an explanation.
The result is a user interface that better matches the way most people think about the tasks they are performing. It empowers them to solve problems rather than follow procedures....
Over the long run, these systems also increase strategic utility by making it easier to accommodate future business changes: changes to product specifications, the organization chart, internal rules and external regulations, business processes, and relationships with other organizations.
Most of us find that those changes are becoming increasingly frequent, which makes strategic agility increasingly urgent....
And there's a Naked Objects website:
Naked Objects version 1 was released in November 2002, since when it has been continuously extended and improved. Many thousands of people have downloaded and used Naked Objects version 1 for exploring the Naked Objects concept and/or for building rapid prototypes of business solutions.
Since November 2003 we have been working on Naked Objects version 2 - the Enterprise Edition. Although built on the same principles, Naked Objects version 2 has been substantially re-architected....
Pawson and Robert Matthews are the founders.
Eitan Suez discusses issues:
if we look at the class of applications known as business applications,
we will find that irrespective of the domain model, support for the following basic features will
always be needed:
1 persistence
the basic ability to store and restore objects from a persistence store
2 object lifecycle management:
creating, viewing, editing, and deleting objects
3 validation
ties in to object creation: what consitutes a valid entry for an object:
which fields are required, what is the set of valid values for a field,
etc..
4 defaults
prototype objects for types
5 search / query
the ability to perform searches / queries against a large repository of objects
6 reporting
for a search, the ability to customize what specific fields to return, in what
order, and how to dress it up for printing (or producing pdfs)
7 authorization
who is allowed to view, edit, create, and delete objects
8 calendaring / scheduling
for objects that are 'schedulable', the ability to view these objects in some
sort of calendar layout, and the ability to perform scheduling activities on
them (change time, date, duration, etc..)
i haven't bothered to make the above list complete. other services should be
on that list (remoting, other aspects of security, transactions, registries,
directories, and in general: guis, and state management, internationalization,
localization)....
the end result should be an app whose objects can be created, edited, viewed,
browsed, searched, reported upon, and much more.
i can think of two frameworks that, at first glance, one might think: "there cannot
possibly exist another pair of frameworks that are as far removed from one another, that
are as polarized from one another." these two frameworks/containers are:
j2ee
nakedobjects
yet i've come to realize that these two frameworks have much more in common than
first meets the eye: they both attempt to provide a framework or container
that generically solves certain aspects of business application development.
the difference lies in the choice of services that each has decided to support.
j2ee makes security and transactions generic. nakedobjects makes the ui generic.
there actually is an overlap: they each address (or try to address) the problem of
generically persisting objects....
what i want to see is more of a "unified field theory" for business application containers
and services, so to speak. a generic blueprint for plugging in services into a completely
specified container, including services that have not even been thought of or
identified today....
Object-orientation was supposed to give us business systems that were much more agile, allowing organizations to enhance their day-to-day operational agility as well as their ability to make strategic adaptations to market changes....
Several of us involved in object-oriented design, however, have speculated that the reason these benefits have not been as substantial as promised, or as quickly realized, is that the principles of object-orientation were being diluted with traditional techniques and technologies.
Three years ago I set out to prove not only that a purer form of these principles would do a better job of fulfilling their original promise, but also that this could be a practical approach for commercial IS organizations. The result of this work is an approach called "naked objects."...
The naked objects approach requires a 1:1 correspondence between the business objects -- such as customer, product, and order -- that users manipulate on the screen and those in the middle tier of the architecture.
That is, business objects must show directly through to the user, instead of being "clothed" in the menus, scripts, and dialogue boxes of a conventional user interface.
Using the Naked Objects framework, the screen representation is automatically generated from the core business objects, without writing a single line of code for the user interface. All the programmer does is specify the business objects themselves: their attributes, their associations with other objects, and the business methods they can fulfill.
When the object definitions are compiled and run, a part of the toolkit known as the viewing mechanism automatically translates an object's specification into its screen representation. Individual objects show up as icons, which can be dragged and dropped, or "opened." This viewing mechanism is truly business agnostic.
With the Naked Objects framework, there is simply no way to provide the user with any functionality except as a behavior encapsulated into an object. When developing a system, designers would learn which behaviors to encapsulate into an object by asking questions such as, "What actions would you want to take with this object?" and "Where might you want to drop this object, and why?"
Business rules are written into the business objects themselves. If Object A cannot be dragged onto Object B, it will instantly flash red to indicate that the action is not permitted. Holding the cursor there for a moment longer will bring up an explanation of why it is not permissible. Right-clicking on an icon brings up a menu list of the actions the user can take.
Several of the actions may be grayed out, indicating that they are not permissible with the object in its current state. Again, holding the cursor on the menu for a moment will bring up an explanation.
The result is a user interface that better matches the way most people think about the tasks they are performing. It empowers them to solve problems rather than follow procedures....
Over the long run, these systems also increase strategic utility by making it easier to accommodate future business changes: changes to product specifications, the organization chart, internal rules and external regulations, business processes, and relationships with other organizations.
Most of us find that those changes are becoming increasingly frequent, which makes strategic agility increasingly urgent....
And there's a Naked Objects website:
Naked Objects version 1 was released in November 2002, since when it has been continuously extended and improved. Many thousands of people have downloaded and used Naked Objects version 1 for exploring the Naked Objects concept and/or for building rapid prototypes of business solutions.
Since November 2003 we have been working on Naked Objects version 2 - the Enterprise Edition. Although built on the same principles, Naked Objects version 2 has been substantially re-architected....
Pawson and Robert Matthews are the founders.
Eitan Suez discusses issues:
if we look at the class of applications known as business applications,
we will find that irrespective of the domain model, support for the following basic features will
always be needed:
1 persistence
the basic ability to store and restore objects from a persistence store
2 object lifecycle management:
creating, viewing, editing, and deleting objects
3 validation
ties in to object creation: what consitutes a valid entry for an object:
which fields are required, what is the set of valid values for a field,
etc..
4 defaults
prototype objects for types
5 search / query
the ability to perform searches / queries against a large repository of objects
6 reporting
for a search, the ability to customize what specific fields to return, in what
order, and how to dress it up for printing (or producing pdfs)
7 authorization
who is allowed to view, edit, create, and delete objects
8 calendaring / scheduling
for objects that are 'schedulable', the ability to view these objects in some
sort of calendar layout, and the ability to perform scheduling activities on
them (change time, date, duration, etc..)
i haven't bothered to make the above list complete. other services should be
on that list (remoting, other aspects of security, transactions, registries,
directories, and in general: guis, and state management, internationalization,
localization)....
the end result should be an app whose objects can be created, edited, viewed,
browsed, searched, reported upon, and much more.
i can think of two frameworks that, at first glance, one might think: "there cannot
possibly exist another pair of frameworks that are as far removed from one another, that
are as polarized from one another." these two frameworks/containers are:
j2ee
nakedobjects
yet i've come to realize that these two frameworks have much more in common than
first meets the eye: they both attempt to provide a framework or container
that generically solves certain aspects of business application development.
the difference lies in the choice of services that each has decided to support.
j2ee makes security and transactions generic. nakedobjects makes the ui generic.
there actually is an overlap: they each address (or try to address) the problem of
generically persisting objects....
what i want to see is more of a "unified field theory" for business application containers
and services, so to speak. a generic blueprint for plugging in services into a completely
specified container, including services that have not even been thought of or
identified today....
posted by Ontario Emperor | 08:00
0 Comments:
Post a Comment
<< Home