From: Simon Vandemoortele Date: 2003-05-01T19:40:01+09:00 Subject: Re: [OO interface design] Pass-by reference VS encapsulation ? On Wed, 30 Apr 2003 at 22:35 GMT, Eric Schwartz wrote: > Why should the Contact care if there's another object with the same > data it has? It's the AddressBook's job to tell you things like > that. One possible solution is to use an Observer pattern to allow > the AddressBook to register itself as being interested in operations > like changing names and optionally disallow them. That way you can > pass around all the mutable object you like, and let the AddressBook > validate any prospective changes. That's certainly a simple solution to my problem. It's my impression though that Dave would go more toward the immutable/mutable + transaction concept. I am guessing this is for extendability, robustness reasons and I am quite confident this is a good idea. With my limited experience however, I am unable to 'see' why; I am trying to envision how the mutable solution would limit me in the future but can't think of anything. (But then, people with limited experience are more shortsighted.) > In this particular case, though, I'd invite you to look through a > phonebook of even a relatively small city and see how many duplicated > names there are. Having some sort of unique key that is not a > person's name would be a better solution, IMO. I've thought about that but it is my belief that one could very easily get away with using names as ID's _in the context of a single person's addressbook_ which is what I am designing. The reason is that human beings tend to use names as ID's for the people they know. When they know two people with the same name, referring to these people tends to get confusing and inefficient. This is best solved by using nicks or some form of name alteration to distinguish the two people in a way that makes sense to oneself and possibly others. > If you'd like to pass around an object and be sure it'll never get > altered by its reciever, then a Contact/MutableContact pair seems > unavoidable. Indeed. Simon PS: As we evolve in this discussion I find myself frightened by the complexity of something that, at first, seemed a rather trivial design. It is starting to look as if the effort required to make the Addressbook I am implementing *really* safe, is more than what I am willing to put into it ... especially since there is a chance it will never be used by any other client than the one I am designing. How does one tell if one is too lazy too think out a decent (future-proof) design or if one is sinning against the YAGNI I idiom ? -- There are 10 types of people in the world... those who understand binary and those who don't.