[Seaside] Smalltalk design advice - how to implement generic
C. David Shaffer
cdshaffer at acm.org
Fri Dec 21 18:20:50 UTC 2007
> 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