Design advice: lists and containment
cdshaffer at acm.org
Sat Nov 5 17:39:19 UTC 2005
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
>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
>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.
More information about the Squeak-dev