Design advice: lists and containment

Welch, Ronald P (US SSA) ronald.p.welch at baesystems.com
Sat Nov 5 19:40:48 UTC 2005


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