<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>Re: [Seaside] Smalltalk design advice - howtoimplement genericbi-directional pointers?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Wow this topic got complex quickly. What happened to good old approach of simply trying a couple of patterns, writing unit tests and refactoring later if it doesn't work out?<BR>
<BR>
Cheers!<BR>
<BR>
-Boris (via BlackBerry)<BR>
<BR>
----- Original Message -----<BR>
From: seaside-bounces@lists.squeakfoundation.org <seaside-bounces@lists.squeakfoundation.org><BR>
To: ch.l.ngre@online.de <ch.l.ngre@online.de>; 'Seaside - general discussion' <seaside@lists.squeakfoundation.org><BR>
Sent: Sun Dec 23 10:15:16 2007<BR>
Subject: RE: [Seaside] Smalltalk design advice - howtoimplement genericbi-directional pointers?<BR>
<BR>
Maybe I can add something to Ramon's aswer. See below.<BR>
<BR>
> -----Mensaje original-----<BR>
> De: seaside-bounces@lists.squeakfoundation.org<BR>
> [<A HREF="mailto:seaside-bounces@lists.squeakfoundation.org">mailto:seaside-bounces@lists.squeakfoundation.org</A>] En nombre<BR>
> de Ch Lamprecht<BR>
> Enviado el: Sábado, 22 de Diciembre de 2007 19:40<BR>
> Para: Seaside - general discussion<BR>
> Asunto: Re: [Seaside] Smalltalk design advice - how<BR>
> toimplement genericbi-directional pointers?<BR>
......<BR>
> Given the examples above, I understand your point. But<BR>
> thinking of the following I don't see an obvious solution:<BR>
> Let's say I have employees and projects where each employee<BR>
> might work on many projects and each project has many<BR>
> employees working on it. Now in a RDB I would have three<BR>
> tables one for each projects/employees and a linking table<BR>
> for the m:n relationship, possibly containing details of the<BR>
> association.<BR>
<BR>
Think about data and objects. May be this can help: consider to see data as<BR>
serialized objects. Data is stupid it can't do anything but to be printed<BR>
somehow. Objects instead are things (automatons) that have behavior. So they<BR>
are less stupid than data. You can ask them to be printed (serialized) in<BR>
different fashions: plain text, a pdf, utf-8, html, binary, etc.<BR>
<BR>
So if you have this less stupid tool just take full advantage from it by<BR>
using them as if they where real instead to try to think you should make a<BR>
whole program with related instances of string like the RDB proposal.<BR>
<BR>
By "as if they where real" I mean to have in mind that they have to honour<BR>
the real objects/concepts of the part of the real world you observed and<BR>
wanted to be modeled in a computer. This often means that you should observe<BR>
and re-observe the details in the real world to understand how to<BR>
review/factorize a design for it's next version.<BR>
<BR>
All this in the example you gave could mean you put some object matching a<BR>
real concept in the middle to cut the circle and, give the effor you take,<BR>
take the cance of adding some value. I'll make a suposition to illustrate<BR>
this: I'll supose that is important for that application to know the use of<BR>
time of those employees for each project they are involved.<BR>
<BR>
Given that I will "cut" that bidirectional knowledge by adding the concept<BR>
of AssignedEmployee. Now each project will have N assignedEmployees and each<BR>
assignedEmployee will know only one employee. In assigned employee the<BR>
project can add appointments affecting the use of time of that employee, a<BR>
meeting afecting all employees, etc.<BR>
<BR>
You can ask to any project for the employees involved in it. And for the<BR>
"problem" of searching the projects in wich every employee is involved you<BR>
use some other object that maintains that convenient "query or index". Lets<BR>
say ProjectsManager knows wich projects it manages so it's easy to select<BR>
projects that satisfies an employee on them.<BR>
<BR>
Smalltalk is mean to be heuristic and intuitive so it's legal to maintain<BR>
concepts as simple and clean as the simplified reality you observe.<BR>
<BR>
*If* in the name of the cpu efficient usage you are tempted to make<BR>
something more "direct" to solve that problem by adding "relations", be<BR>
conscious that you are polluting that conceptual simplicity. So try to<BR>
select only those optimizations that guarantees your design to keep growing<BR>
in conceptual complexity. In other words remember that optimizations are too<BR>
often overestimated (decided before analizing real numbers/usage experience)<BR>
become pitfalls of it's own complexity and can easily prevent your model to<BR>
scale in conceptual complexity that you will need for sure if your<BR>
application has any success.<BR>
<BR>
For the given case to solve that search "problem" an index could be easily<BR>
be made with a dictionary without pollutiong relationships in your model. If<BR>
your boss, customer or whatever changes it's mind about the importance of<BR>
that search you discard the index an maintain intact your model.<BR>
<BR>
cheers,<BR>
<BR>
Sebastian<BR>
<BR>
> Users of my application would expect to be able to search for<BR>
> all the employees working on a given project and vice versa.<BR>
> Trying to find an OO model to represent this, I end up with<BR>
> three Classes that correspond to the three tables mentioned<BR>
> above ( maybe this is wrong already??).<BR>
> Each of the project/employee instances would hold a<BR>
> collection of association objects. Each association object<BR>
> would have instance vars to reference a project and an<BR>
> employee. But that way I would have bidirectional links on<BR>
> both sides of the association object...<BR>
> I could avoid the collections of associations in<BR>
> employee/project and create class-side methods in the<BR>
> association class instead answering collections of<BR>
> associations referencing a given employee (or project). But<BR>
> that seems even worse to me - like simulating a database table.<BR>
><BR>
> I would be very thankful if anybody could point me into a<BR>
> better direction, ( or recommend some books to read )<BR>
><BR>
> Regards, Christoph<BR>
><BR>
><BR>
><BR>
><BR>
> _______________________________________________<BR>
> seaside mailing list<BR>
> seaside@lists.squeakfoundation.org<BR>
> <A HREF="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A><BR>
<BR>
_______________________________________________<BR>
seaside mailing list<BR>
seaside@lists.squeakfoundation.org<BR>
<A HREF="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A><BR>
</FONT>
</P>
</BODY>
</HTML>