From: Simon Vandemoortele Date: 2003-05-02T05:03:01+09:00 Subject: Re: [OO interface design] Pass-by reference VS encapsulation ? 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.