Hi Markus

This is how I would do it:

I'd not subclass Collection but rather create a root domain model class
which holds the collections of addresses and articles etc. as instance
variables (with Magma for example you need a root object). In this class you
can provide the needed logic to access the address- and article collections.
You may have #addAdddress: or #removeArticle: or to check if an address can
be removed you say something like:

isAddressRemovable: anAddress
    articles detect: [ :each | each address = anAddress ] ifNone [^true].
    ^false

Like this, there is a much better encapsulation and you only give the access
which is needed (and which you can control).

Adrian

_____________________
Adrian Lienhard
www.adrian-lienhard.ch
www.netstyle.ch
----- Original Message -----
From: "Markus Fritsche" <Fritsche.Markus at gmx.net>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Friday, July 11, 2003 4:14 PM
Subject: Constraints with OODBs/ Collections?


> Hi!
>
> It's not direct squeak related, but may some experienced
> programmers know how to "do it the right way(tm)"?
>
> >From http://swiki.squeakfoundation.org/sea/90:
> ______________________________
> I'm thinking about using an OODB as the persistence layer. Why? Because I
> won't have to duplicate class hierachy and behaviour in the database and
the
> logic.
> The two most complicated things in the database are assemblies and the
print
> output.
> There are two types of assembles: an assembly and a subassembly. Theses
have
> to be editable. An order usually is an order for an assembly, but it don't
> have to. The assembly could "evolve" due to changes made to a machine,
where
> the assembly is a part of. So, an assembly must be versioned, and editing
an
> assembly have to result in a copy with a new version if the assembly is
> referenced anywhere in the system.
> Sometimes, an assembly is of no use anymore (if it is not referenced in an
> order, i.e. it was a version temporary between two edits). It then should
be
> "garbage collected".
> I think this could be implemented best using a OODB.
>
> The implementation using an OODB leads to another problem: How do you
ensure
> some constraints? For example, if you have a supplier for an article
(being
> used in an assembly), you should ensure that on cannot delete a used
> (referenced) address out of the addresses collection. There are more
constraints
> here, like ensure that article numbers are only used once in the
collection of
> articles.
> A possibility is to subclass the used collection class. So if I want to
> introduce some constraints for articles, I subclass OrderedCollection,
> introducing an ArticleCollection. In the #add: and remove:# methods, I
check my
> constraints. But I think there is a better way :-)
> ______________________________
>
> So is subclassing OrderedCollection the right way? Or should
> I solve the problem using another solution (maybe a
> ConstrainedCollection which stores it's constraints as blocks)?
>
> Kind regards, Markus
>
> --
> SIGSTOP
>
> +++ GMX - Mail, Messaging & more  http://www.gmx.net +++
>
> Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!
>
>