[Seaside] Smalltalk design advice - how
toimplement genericbi-directional pointers?
aaron at cocoanutstech.com
Sun Dec 23 19:21:19 UTC 2007
I'd like to thank Sophie and Christoph for asking an excellent
question. And thanks to Ramon, Colin, David, Amos, Sebastian and
others for lending a hand.
This thread strikes a real chord with me. I believe that if you model
the domain effectively then the application feels like it can write
itself. That is, spend time developing your critical domain objects
and behavior before you start writing your app. If you find that in
your app you are writing a lot of code, you are probably doing
something wrong at which time you should revise your domain model.
What Sophie, Christoph, and myself are really asking is, "How should
I go about developing my domain model". 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?"
Ramon mentioned "Class Responsibility Collaborator" models, or just
"CRC cards" for short. That terminology is new to me and the idea is
pretty cool. For the uninitiated, here's a few links:
Bitmap scans of the actual handwritten CRC cards used in the creation
Review of "Ecode", a CRC card design tool for Squeak:
So I installed "Ecode" from SqueakMap into my 3.9 image taken from
the Seaside one-click-experience. After running Ecode I could no
longer "yellow" click on the desktop or other areas without getting
an exception thrown... so I guess it is not compatible with the
current Squeak. The idea of Ecode sounds pretty stellar and basically
the kind of tool I want to use. Does anyone have suggestions about
I've grown accustomed to having a visual tool where all I concentrate
on is the domain objects, what their responsibilities are, and how
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.
I think Sophie was looking for some pattern along the lines of:
| car tire1 |
car := Car new.
tire1 := Tire new.
car add: tire1 toBothSidesOfRelationshipWithKey: 'tires'.
The message "add: object toBothSidesOfRelationshipWithKey: string"
would attach the tire to the car and, if you had modeled the inverse,
it would tell the tire what car it was placed on. So the 'tires'
relationship and the optional inverse 'car' relationship would have
to be modeled somehow. Like maybe Tsunami or maybe Magritte but I
don't know what I'm talking about here because I haven't cracked open
those two Squeak frameworks yet.
Ramon, maybe you can clarify. You mentioned your Tsunami framework
but in the same breadth alluded that we shouldn't use it? Or I
misunderstand. In what situations *should* we use Tsunami or is it
that you once felt it was necessary but later learned it isn't? In
the Tsunami framework it mentions inspiration from the book
"Streamlined Object Modeling" which has examples for both Java and
Squeak. Would you say this is an excellent book for us new guys to read?
Thanks for listening,
On Dec 23, 2007, at 2:40 AM, Ramon Leon wrote:
>> Let's say I have employees and projects where each employee
>> might work on many projects and each project has many
>> employees working on it. Now in a RDB I would have three
>> tables one for each projects/employees and a linking table
>> for the m:n relationship, possibly containing details of the
> If you're trying to think in objects, the first thing you need to
> stop doing
> is starting by thinking about how you'd do it in a relational
> Relational database are meant to store data in such a manner that
> it'll work
> for any model in any application, all data and no behavior. That
> isn't OO
> and that's not what you need to think about.
>> Users of my application would expect to be able to search for
>> all the employees working on a given project and vice versa.
>> Trying to find an OO model to represent this, I end up with
>> three Classes that correspond to the three tables mentioned
>> above ( maybe this is wrong already??).
> Why? Seriously, you're still thinking relationally, you're talking
> nothing but data and searching.
>> I would be very thankful if anybody could point me into a
>> better direction, ( or recommend some books to read )
>> Regards, Christoph
> First, stop thinking about the data, programs aren't about data,
> about behavior. You have to ask yourself what is this program
> going to do,
> what is its purpose, what does it accomplish for the user. Is the
> about projects, or users, and which one is it going to be centered
> What objects are you going to need most? Modeling a program is
> about making
> choices, picking a direction, and going for it. Trying to keep
> bidirectional links everywhere is just a way to avoid making a
> decision. An
> object model isn't a relational schema, it's not supposed to be
> it's supposed to be opinionated.
> Trying to make a model that works for all cases (relational db's)
> just leads
> to a model that doesn't work well for any case. Pick your most
> use cases and make the model work well for them, and make sure to
> let the
> programs actual behavior dictate which solution is best. Don't sit
> down and
> design your object model like a relational schema where you name
> all the
> attributes and try and normalize the data, rather, use CRC cards
> and figure
> out how your objects collaborate, behaviorally. Don't bother
> listing the
> attributes, that doesn't matter, you can figure that out at
> If you think hard enough, and find that your app really is just
> data with
> little if any behavior, then you really just stop thinking about
> trying to
> make a *good object model* and just dump the data to the screen in the
> easiest manner possible, be it sql queries or an active record, it
> really matter. Object models are best suited for behaviorally complex
> Ramon Leon
More information about the seaside