🚀 go-pugleaf

W dniu 2012-05-11 08:39, Jacek Czerwinski pisze:
> Są pewne struktury (kolekcje obiektów). Na etapie ich budowania są
> dostępne (jakby public). Potem jest etap ich używania i traktujemy jako
> niezmienne (jakby uzyskały swoiste final), ale nie jest to zabezpieczone.
>
> 1. czy jest takie czary-mary, że w pewnym momencie jest to immutable
> Colection również immutable elementów. Nie chciałbym strzelać z armaty
> do wróbla. Można się spodziewać, że referencje do w/w gdzieś są
> zapamiętane, więc podmiana na siostrzaną strukturę nie wchodzi raczej w
> grę.

na samą listę, zrób dekorator do List który pamięta czy kolekcja została 
już zablokowana, nie pozwala na odblokowanie, i jeśli zablokowana to 
settery rzucają wyjątki.


na elementy, po prostu trzymaj kopie w liście (Cloneable), nie 
referencje do oryginałów. A referencje do kopii zwracaj opakowane tak że 
settery rzucają wyjątki.


-- 
Arivald

Ja to zazwyczaj robię tak, że kolekcja (lista, zbiór, whatever) jest 
"mutable" wewnątrz jakiejś klasy, która odpowiada za jej budowanie.
Po czym ta klasa ma metodę:

public Collection<Something> getSomethings() {
	return Collections.unmodifiableCollection(mSomethings);
}

Trick polega na tym, że mSomethings nadal jest "mutable" więc "w razie 
czego" wewnątrz klasy można aktualizować zawartość, ale już na zewnątrz 
można z tej kolekcji tylko czytać (kwestie Refleksji pomijam, bo tu nikt 
i nic nie jest bezpieczne).

A, no i jest jeszcze Guava i jej ImmutableList, które na hocki-klocki 
jak wyżej nie pozwala i jest naprawdę immutable.

-- 
npe