On Thu, 01 May 2003 at 19:38 GMT, Dave Thomas wrote:
> Simon Vandemoortele wrote:

>> Wouldn't I still need an object that keeps track of all the instantiated
>> contacts. How else am I going to generate a sorted list of contact names
>> for the UI ?

> Surely all the Contacts that you search are the persisted ones: you 
> don't want folks looking at possibly inconsistent reified ones.

That's where I don't follow you: in my scheme contacts are not persisted
until the user closes the application. Therefore I do not have that
clean separation 'consistent persisted contacts'/'inconsistent reified
contacts' and that's a problem I am still trying to solve (see my
reply to MikkelFJ).

> > Who is going to answer sophisticated search queries (give
> > me all contacts born between 1977 and 1987.) I could achieve this using
> > the ObjectsSpace in my client but is that really good design ?
> > Especially since many clients are probably going to want that query
> > functionality ...

> Why not Contact itself? For example, in my web application, class User 
> has class methods

What you are in fact suggesting is that I put the responsibility that is
currently in an Addressbook instance, in the Contact class. I don't know
what to think of that ... why merge two different aspects in one class
(the contact management interface and the contact interface) ? then
again; the Addressbook class is strongly coupled to the Contact class
anyway.

> Anyway, a suggestion. Code your application. Code it many different 
> ways. And see what you think of each. In some versions make a point of 
> relaxing what you believe to be good design practices in favor of doing 
> what seems natural. In others, design the snot out of it. And in the 
> end, see which application feels 'right.'

That's what I'm thinking too.

> And please let us know.

Will do. 




-- 
There are 10 types of people in the world... 
those who understand binary and those who don't.