"Dave Thomas" <dave / pragprog.com> wrote in message
news:3EB11114.8090605 / pragprog.com...

> However, that's not the way I'd go. Instead I'd make the objects all
> mutable, and have a 'save' method that stored them away on a change.
> This is what I did last year when I wrote a fairly large web-based
> registration and ordering system in Ruby.

This is essentially also how a record works in a database query in the
Microsoft DAO / ADO object models (known from MS Access and as wrappers
around OleDB).
You read through the set of returned records. The recordset could be created
by searching a name. If you wish to change a contact, you call the Edit
method. Then modify the fields and eventually call Update. Transactions can
be wrapped around this.
This is what I did many years ago for a multiuser address database system
sitting on single Access file. To handle the multi-user scenario I listened
to conflicts reported on Update (and quite a few other scenarios).

In a non-distributed OO design I would not be overly concerned with the
potential dangers of some external piece of source changing the Contact
object in the original design proposal. Things can easily become
over-engineered. If access rights become a concern later, a private flag can
control access mode and update methods can check this flag. If there is no
write access an exception is thrown. Doing the check against access rights
can also be extended to generate notifications against listeners (such as
the AddressBook and potentially all interested clients).

At the point where access control becomes important, you are probably
working with SOAP, RCP, sockets or similar interprocess communication
facilities and you then have a host of other concerns.

Mikkel