Re: [Seaside] Smalltalk design advice - howtoimplement genericbi-directional pointers?
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?
Cheers!
-Boris (via BlackBerry)
----- Original Message -----
From: [hidden email] <[hidden email]>
To: [hidden email] <[hidden email]>; 'Seaside - general discussion' <[hidden email]>
Sent: Sun Dec 23 10:15:16 2007
Subject: RE: [Seaside] Smalltalk design advice - howtoimplement genericbi-directional pointers?
Maybe I can add something to Ramon's aswer. See below.
> -----Mensaje original-----
> De: [hidden email]
> [[hidden email]] En nombre
> de Ch Lamprecht
> Enviado el: Sábado, 22 de Diciembre de 2007 19:40
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] Smalltalk design advice - how
> toimplement genericbi-directional pointers?
......
> Given the examples above, I understand your point. But
> thinking of the following I don't see an obvious solution:
> 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.
Think about data and objects. May be this can help: consider to see data as
serialized objects. Data is stupid it can't do anything but to be printed
somehow. Objects instead are things (automatons) that have behavior. So they
are less stupid than data. You can ask them to be printed (serialized) in
different fashions: plain text, a pdf, utf-8, html, binary, etc.
So if you have this less stupid tool just take full advantage from it by
using them as if they where real instead to try to think you should make a
whole program with related instances of string like the RDB proposal.
By "as if they where real" I mean to have in mind that they have to honour
the real objects/concepts of the part of the real world you observed and
wanted to be modeled in a computer. This often means that you should observe
and re-observe the details in the real world to understand how to
review/factorize a design for it's next version.
All this in the example you gave could mean you put some object matching a
real concept in the middle to cut the circle and, give the effor you take,
take the cance of adding some value. I'll make a suposition to illustrate
this: I'll supose that is important for that application to know the use of
time of those employees for each project they are involved.
Given that I will "cut" that bidirectional knowledge by adding the concept
of AssignedEmployee. Now each project will have N assignedEmployees and each
assignedEmployee will know only one employee. In assigned employee the
project can add appointments affecting the use of time of that employee, a
meeting afecting all employees, etc.
You can ask to any project for the employees involved in it. And for the
"problem" of searching the projects in wich every employee is involved you
use some other object that maintains that convenient "query or index". Lets
say ProjectsManager knows wich projects it manages so it's easy to select
projects that satisfies an employee on them.
Smalltalk is mean to be heuristic and intuitive so it's legal to maintain
concepts as simple and clean as the simplified reality you observe.
*If* in the name of the cpu efficient usage you are tempted to make
something more "direct" to solve that problem by adding "relations", be
conscious that you are polluting that conceptual simplicity. So try to
select only those optimizations that guarantees your design to keep growing
in conceptual complexity. In other words remember that optimizations are too
often overestimated (decided before analizing real numbers/usage experience)
become pitfalls of it's own complexity and can easily prevent your model to
scale in conceptual complexity that you will need for sure if your
application has any success.
For the given case to solve that search "problem" an index could be easily
be made with a dictionary without pollutiong relationships in your model. If
your boss, customer or whatever changes it's mind about the importance of
that search you discard the index an maintain intact your model.
cheers,
Sebastian
> 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??).
> 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.
>
> I would be very thankful if anybody could point me into a
> better direction, ( or recommend some books to read )
>
> Regards, Christoph
>
>
>
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Locked
