[Seaside] Smalltalk design advice - howtoimplement genericbi-directional pointers?

[Sebastian Sastre]

> What Sophie, Christoph, and myself are really asking is, "How 
> should I go about developing my domain model".

Good question. I think is maintaining the less complex objects that could
possibly honour the real life concepts/objects you want included. Then you
implement them in smalltalk and see what happen: or your proposed model is
enough or you need to refine/review.

 And more 
> specifically "I have an idea of how to do this from my past 
> experience, but given the new world of Squeak and Smalltalk, 
> what's the best practice?"
>
The best pattern is no pattern: just the appropiate model for you. You said
that have an idea from the past knowledge. That can help as much as can
complicate things. Reuse the best of what you have and do not hesitate in
unlearning bad practices. A step backwards in a path that is leading you to
the wrong way could be a step forward. I use to "implode" bad
ideas/practices as soon as I can/become aware of. It could happen even
inside you own smalltalk designs.

In short: stop thinking relationalish. Start thinking objetish.

This is the same: be sure to stop trying to model the world arround you as
relationed data. That trend is founded in a mathematical model and not
reality. Use one of the main advantages smalltalk offers you: modeling real
concepts directly.

We are so used to model indirectly that we forgot we can model directly. By
modeling indirectly I mean: "to model reality using a relational model" that
is one degree of complexity guaranteed for everythig you try to think about.
Tables are layouted data. No matter they are html tables in a page or in a
RDBMS. They are not the ideas that provides fundation to the concepts. They
are like a photography of the concept. Objects are concepts.

To question about everything you observe and abstract behavior will help you
a lot more than identifying N to 1 relation between strings.

Sometimes you don't have the idea so you can start to explore by a first
aproximated proposed model. Then you test it and refactor what you need as
Boris said.

Is so much like real life that sometimes I'm amazed how easily we miss the
obvious.

...
> Let's talk again about the "Car" and "Tire" objects. I agree 
> with Ramon that generally a Car needs to know about the Tire 
> objects but the inverse is not important. A Tire can be 
> placed on a different car and it shouldn't care. But what 
> about a luxury car? Is that any different? Could be. The Tire 
> might want to tell the car when its air pressure is low. For 
> this it seems plausible that the tire might want to know that 
> it is attached to the Car, that way it can send a message to 
> the Car when it's time to replenish the air. You could still 
> argue that the Car could "ping" the Tire every five minutes 
> to find out the air pressure, or perhaps once each time you 
> turn on the ignition, so it all depends.

Then you're talking about the need of a loose coupled relation. The tire can
announce that it's air pressure is low. Objects that are aware of the
existance of that tire can have the discern of wanting to register about
that event of that tire and react to it. Smalltalk user interfaces are made
on that basis from decades. Ramon's Leon has wroten a good post in it's blog
about Announcements framework.

Almost allways objects should not know about "their parents". But parents
often want to know what is going on with it's children even when the
children do not pass a message "directly" (hard coupling). 

Take a look in events and announcements, that will help in those, not rare,
scenarios

Cheers!

Sebastian