Design advice: lists and containment

Mark Mayfield 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
OO programming.

Mark Mayfield.


>Jim,
>
>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:
>
>http://www.amazon.com/exec/obidos/tg/detail/-/0130668397/103-0048414-515
>2669?v=glance
>
>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:
>
>http://www.streamlinedmodeling.com/papers/collaboration_patterns.pdf
>
>
>Ron
>
>----------=-=-=-=-=-=-=-=-========oOo========-=-=-=-=-=-=-=-=----------
>mailto:Ronald.P.Welch at baesystems.com                Phone:(607)770-3701
>BAE SYSTEMS                600 Main St Johnson City, NY, USA 13790-1888
>----------=-=-=-=-=-=-=-=-===================-=-=-=-=-=-=-=-=----------
>
>-----Original Message-----
>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://
>www.pragmaticprogrammer.com/ppllc/papers/1998_05.html
>
>> 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 mailing list