[TYPO3-dev] Design Strategy Issue: Put ObjectStorage into Value Objects??!!

[Christian Stüdemann]

Dear all,

I'm not sure, if this is the right way, but I did the following in first 
place:
1. Inside the Value Object I use an array instead of the ObjectStorage, 
because I don't want the Value Object to "know" about entity structures 
like ObjectStorages. Thus I transfer the ObjectStorage data to the Value 
Object using ObjectStorage::toArray().
2. Inside the Value Object I make a deep copy of the array to make sure 
that nobody changes neither the content of the array nor the content of 
the stored array items.

That's "immutable" as far as I can go here...

Best regards,
Christian

Am 02.01.2015 um 01:01 schrieb Christian Stüdemann:
> Hi all,
>
> I've got an immutable Value Object "Filter" describing a set of filter
> criteria and therefor storing lots of strings, booleans etc. Now I want
> to setup a filter for "categories", but these categories are part of my
> Repository, thus they are Entities and they are internally stored to an
> ObjectStorage.
>
> If I would simply add "$categories" as a property to my "Filter" class,
> I would make the Value Object non-immutable, because it stores an
> ObjectStorage (mutable) with Category entities (mutable).
>
> What kind of implementation would you recommend?
>
> First ideas:
>
> a) Clone the ObjectStorage to make it immutable inside the "Filter"
> class, but the entities are still mutable and cloning them wouldn't be a
> good idea, would it?! (Converting the ObjectStorage to an array of
> entities would be nearly the same.)
>
> b) Store an array of UIDs to "Filter" instead of the actual entities and
> the ObjectStorage. This is easy to be made immutable, but it does not
> reflect the objects, thus I have to call the Repository each time I want
> to work with the objects.
>
> c) ??!! Still thinking...
>
> Any ideas?
>
> Best regards,
> Christian