[Seaside] Smalltalk design advice - how to implement generic bi-directional pointers?

C. David Shaffer cdshaffer at acm.org
Fri Dec 21 18:20:50 UTC 2007

itsme213 wrote:
> I don't think I have grasped the "Smalltalk Way" to deal with this and am 
> looking for some design advice ...
I understand your followup to some of the other replies.  Yes, it is 
certainly reasonable to have "bidirectional pointers" for some kinds of 
things (event tire-car...if it makes sense in your problem domain).  I 
understand that you want a turnkey solution to building them.  I don't 
think one exists because I think most developers find that they are 
seldom needed (and if you need them a lot then you're either working way 
outside my problem domain or you need to re-think your data model).

That being said, one answer (I can't say if it a "Smalltalk Way" or just 
something that seems reasonable to try in the absense of macros, DNU 
hacks etc) is to turn your relationships into objects.  So a House 
doesn't hold a collection of rooms.  It holds a RoomHouseAssociation.  
This association makes sure that when a room is added, the room knows 
which association (and therefore which house) owns it.  You can make 
generic connectors of this sort (OneToManyAssociation, 
ManyToManyAssociation) but I don't work in a problem domain where this 
is useful.  If the few cases where relationships deserve first-class 
objects, I create a new type for them.  I believe the domain-specific 
version of this has appeared as a common OO design pattern (but the name 
might not be "Association").  You should track down this design pattern 
because it will undoubtedly give you a nice leg up on the API.


More information about the seaside mailing list