Design advice: lists and containment
afunkyobject at yahoo.com
Sun Nov 6 20:47:47 UTC 2005
> 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
Well, a bookmark strikes me as very nearly a "value" object (with no extrinsic
references) but you may have good reason for doing it.
> 2) To add a bookmark to a user, it now takes two steps:
> user bookmarks add: bookmark.
> bookmark user: user.
I like to let my domain keep these relationships maintained, something like.
"Clean up if moving aBookmark from a prior user.."
aBookmark user ifNotNil: [ aBookmark user removeBookmark: aBookmark ].
bookmarks add: aBookmark.
aBookmark user: self
> 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.
Only if the Bookmark is not referenced. ;)
> 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."
For me, this is the key to the answer to the question. I don't believe in
writing code meant to guard against (potentially) incorrect code elsewhere; if
its all your own code then you'll make it "compatible" with itself. You can't
prevent misuse everywhere anyway, so there may be little point in copy of the
collection that will help with misuse in merely one place.
> 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?
If you returned a copy, right.
More information about the Squeak-dev