Re: [OO interface design] Pass-by reference VS encapsulation ?

"Simon Vandemoortele" <[e-mail]> wrote
in message news:gFdsa.70370$[e-mail]...

> There is one thing that still puzzles me though: whether to allow for a
> 'forbidden/incomplete' object to exist at any point or not. Suppose I
> decide that a Contact instance without a 'Name' is utterly pointless and
> should _not_ be entered in the addressbook at all. It is easy to have
> contacts refuse inconsistent or forbidden data (like an empty name or a
> wrong birth-date format) but how do I make sure all contacts that are
> created are (or become) consistent ?
>
> Given the way I am currently going with this design I see 2 ways to
> implement this:
>
> [1] Make it impossible to create an 'incomplete' contact by requiring
>     the name at construction (and making sure it cannot be set to nil or
""
>     afterward).
>
> [2] Allow clients to create an 'incomplete' (nameless) draft version of
>     the contact and have them call some #validate function that checks
>     the completeness of the contact and creates the definitive version.

The problem is very relevant - I have seen it many times.

First, it is worth being aware that there is the data, and the container.
The actual unique key is only relevant in context of the container (the
index).
Therefore this question has very much to do with implementation - how long
can you wait until requiring correct data.

There are a number of ways to look at your data that might affect the
decision.

As a Relational Database Record. In this case you can view the name as the
"Primary Key". Policy here is that you general can modify any fields but the
point where you update your record, the database engine may complain about
the key not being unique. In the database you can also choose not to require
a unique primary key.

In the Contact database you certainly don't want to have unique keys -
instead you want to list the prospects you user might be interested in after
a search. What you would do is to assign a new contact a new id, such as a
customer number. This id is dynamically created as needed so it is never an
issue to get it unique (actually it is an issue in distributed systems, but
never mind that). But for the purpose of a design excercise, lets continue
to assume we need a unique name.

In object models you can create a detached child object, fill it in with
data, and eventually add the object to a container in the object model.
Here there is no reason to require uniqueness before the time where the
object is appended.

Another way to deal with object models is to use the AddNew method. In this
case the child object (here contact) is both created and appended at the
same time. AddNew will then require a unique name and complain immediately
before you get a chance to add more data.

I generally do not like object models where you create detached objects that
are later appended. This gives all sorts of problems - typically an object
also has a reference to the root of the object model, or the "Document".
While being detached there is no document and many operations work
differently. Another problem is issues with lifetime management and even
allocation although this is less relevant in garbage collected languages
unless the object references external resources such as files.

You can also choose AddNew, but allow an inconsistent definition until a
call to an Update method - this is also nice if you later want to change the
name.

A perfect example of this problem are files in a filesystem. Generally you
first use AddNew, as in create_file(filename) or fopen(filename).
In Unix a file can also exist anonymously without having a name, or it can
have multiple names. In relality the file is identified by a unique id - the
inode number. For the average user you don't see the inode so appears like
an AddNew system.

> I would like to go for [1] since it is very simple but in many cases it
> just shifts the complexity to the client since the client now has to
> buffer data in a structure that probably looks a lot like Contact until
> it has enough to create a valid contact.
> So I guess I should use [2] but I don't know how to do that ... do I
> create two classes of objects: IncompleteContact and Contact. Generate
> the second from the first through validation ?

For [2] you can use a factory method to create the object and a second
method to add the object to the system. This is the save operation suggested
by Dave.

But there isn't really a right way to do it. It's all about the language and
the object model you generally want. I guess you can look at REXML versus
DOM object model to see the variation in design of object models.

When possible I like to think of a unique key as something that does not
belong to an object but rather something that belongs to a relation between
the current object and a mapping object. This relation can be created,
removed and changed at any time (Here the mapping object would be
AddressBook or something inside it). Obviously search facilities will only
be available when the mapping relation exists but the object can easily
exist without it. This view makes it possible to let an object have any
number of values that kan be unique in some relations and non-unique in
other relations. You can in other words index you object in arbitrarily many
ways.
To deal with the life time issue you can have one ownership relation that
optionally maps a dynamically created unique id to the object (like the
inode).
If this unique id relation is broken, you should also break all other
mapping relations i.e. remove the unique name from the name index etc. and
eventually deallocate the resources tied to the object (such as memory in
non garbage collected systems).


Mikkel