Hey Jim,

I'll weigh in with my personal experience...

Jim Menard wrote:

>I need some design advice. This problem is also applicable to other
>languages, but for some reason I seem to agonize over it more when I'm
>trying to "think in Smalltalk".
>  
>
I've had times like that too.  Probably b/c you have fewer things to
worry about in Smalltalk and, maybe, because a bad model is obvious to
everyone :-)  One thing that I know pretty well now, though, is that
making the wrong decision in Smalltalk has fewer repercussions than in
many other languages (particularly those with manifest typing).

>A user has a collection of bookmarks. Each bookmark is therefore owned
>by a user. (In my model, a bookmark may also be owned by a group of
>users instead of an individual user, but let's not confusing things
>for now.)
>
>So, a user has a bookmarks instance variable that is a collection. It
>would also simplify my code to let each bookmark have a user instance
>variable that "points" back to the user.
>
>1) Is that kosher? Is it good practice to have a bookmark hold on to its user?
>  
>
The user (or group) becomes the "owner" of the bookmark and the bookmark
has a backreference to its owner.  Nothing wrong with it design-wise as
far as I'm concerned.  It falls apart as soon as the model permits more
than one owner for a given bookmark.  Doesn't sound like it will be a
problem for you though.

>2) To add a bookmark to a user, it now takes two steps:
>
>    user bookmarks add: bookmark.
>    bookmark user: user.
>
>Is there a better way? I could easily put that code into, say, a user
>method. Is that how it is commonly done?
>  
>
Looks pretty typical.

>3) When I remove a bookmark from a user's collection, will the
>bookmark be GC'd? I think so, but I want to be sure.
>  
>
No worries.  The "back reference" won't prevent the Bookmark from being
GC-ed.

>4) The accessor method on user that returns the bookmarks means that
>callers can manipulate the list. My first instinct is to say, "Don't
>worry about it. I'm not developing a library, so I will know how to
>use the collection properly." Should I worry? Should the accessor
>method return a copy of the bookmarks, so manipulation of the contents
>won't affect the user's bookmark list? If so, then I have to provide
>addBookmark: and removeBookmark: methods, right?
>  
>

I've seen people take the "answer a copy" route.  I don't think it is
generally necessary although I have see cases where the copy was needed,
these are usually the exception rather than the rule.  Generally if
someone hands me a collection I consider it immutable unless I am told
otherwise.  Normally the opposite assumption leads to problems.

David