Design advice: lists and containment
markleem at satx.rr.com
Sun Nov 6 15:07:31 UTC 2005
And if anyone would like to discuss the patterns and strategies listed in
our book, my wife Jill Nicola and I are always interested new and better
ways to design things.
Now that we have a good handle on coming up with candidate objects and
establishing collaborations between them, we are concentrating more and
more these days on goal-oriented messaging and the algebraic nature of true
>These types of design decisions always come down the being
>more of a art than a science, so the usual caveat about there
>being "no right answers" applies. However, that being said,
>one of the best sources of advice for these types of questions
>that I have found comes from:
>For a introduction to the methodology outlined in the book you
>may want to check out the following white paper at the
>streamlined object modeling web site:
>mailto:Ronald.P.Welch at baesystems.com Phone:(607)770-3701
>BAE SYSTEMS 600 Main St Johnson City, NY, USA 13790-1888
>From: Bert Freudenberg [mailto:bert at impara.de]
>Sent: Saturday, November 05, 2005 2:22 PM
>To: The general-purpose Squeak developers list
>Subject: Re: Design advice: lists and containment
>Am 05.11.2005 um 16:05 schrieb Jim Menard:
>> 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?
>It's not "good" practice, IMHO. It creates a strong coupling between
>bookmarks and users.
>Also, the object reference graph is not acyclic anymore. DAGs are
>easier to deal with, like when serializing.
>> 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?
>Yes. Again, this reduces coupling, the code above does break the
>encapsulation. There's even a law against this ;-)
>It's called Demeter's Law, see, for example, http://
>> 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.
>Yes, if nothing else holds a reference to that bookmark.
>> 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?
>Well, it depends what your intentions are :)
>> 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?
>Yes, for the same reasons as above. As a more efficient alternative
>to returning a copy, you could provide a bookmarksDo: method.
>But, take all of that with a grain of salt ;-) Such rules are never
>absolute. I, personally, would just expose the bookmarks collection
>in that situation.
>- Bert -
More information about the Squeak-dev