Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Niezmienne (immutable) ale od pewnego czasu

38 views
Skip to first unread message

Jacek Czerwinski

unread,
May 11, 2012, 2:39:40 AM5/11/12
to
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ę.

2. czy w ogóle jest się czym przejmować?

Arivald

unread,
May 11, 2012, 3:18:13 AM5/11/12
to
W dniu 2012-05-11 08:39, Jacek Czerwinski pisze:
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

nullpointer

unread,
May 11, 2012, 2:05:45 PM5/11/12
to
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
0 new messages