[Seaside] Smalltalk design advice - how toimplement genericbi-directional pointers?

Ramon Leon ramon.leon at allresnet.com
Sun Dec 23 07:40:49 UTC 2007


> 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 
> association.

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 database.
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 about
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, they're
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 program
about projects, or users, and which one is it going to be centered around?
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 agnostic,
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 important
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 implementation
time.

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 won't
really matter.  Object models are best suited for behaviorally complex
applications.

Ramon Leon
http://onsmalltalk.com



More information about the seaside mailing list