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

Colin Putney cputney at wiresong.ca
Sat Dec 22 23:03:08 UTC 2007

On Sat, 22 Dec 2007 22:39:38 +0100, Ch Lamprecht wrote:

> 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??). Each of the project/employee instances 
> would hold a collection of association objects. Each association 
> object would have instance vars to reference a project and an 
> employee. But that way I would have bidirectional links on both sides 
> of the association object...
> I could avoid the collections of associations in employee/project and 
> create class-side methods in the association class instead answering 
> collections of associations referencing a given employee (or 
> project). But that seems even worse  to me - like simulating a 
> database table.

It seems to me that you're trying too hard to make your model reflect 
"reality." Don't worry about that. Instead, think about what you want 
your application to accomplish. You want to be able to list the 
employees that are assigned to a project? It's perfectly reasonable to 
just have projects keep a collection of employees. If at some point you 
need to get the reverse - projects an employee is involved with, just 
get all projects and select the ones that reference that employee. 
Unless you have massive amounts of data, that'll work just fine. 

Perhaps your application would be best served by a master list of 
employee->project assignments. Maybe it needs a reverse index. Maybe 
not. Maybe you need a date range associated with the assignment so you 
can see what the employee has been invoved with in the past or his 
schedule for the future. In that case, an temporal index might be 
what's required.

The best thing to do is start by using the simplest model that captures 
the information you need to present in your user interface, for the 
smallest set of features that will be useful. As go forward, the UI 
will get richer, and the model will evolve to meet the needs of the UI.


More information about the seaside mailing list