2012-05-07 11 views
5

niemodyfikowalne lista w Javie może być utworzony jako:Jaki jest rodzaj niemodyfikowalne listy w java

List<String> unModifiableStringList = Collections.unmodifiableList(myActualModifiableList); 

To jest w porządku, ale to, co jest rzeczywistą typu runtime listy zwróconej przez wyżej funkcji? Jak możemy uzyskać dostęp do tej klasy? Czy to możliwe?

UPDATE: Właściwie muszę wiedzieć, w czasie kompilacji, że lista niezmienne jest modyfikowany, bo mamy do czynienia z wieloma listami, z których niektóre mogą być modyfikowane, a inne nie. Czy śledzenie jest bardzo kłopotliwe?

Odpowiedz

8

Właściwie podczas kompilacji muszę wiedzieć, że zmienia się lista niemodyfikowalna.

To nie jest możliwe.

Przynajmniej nie jest to możliwe bez utworzenia zupełnie innego interfejsu kolekcji/hierarchii klas. I to jest zły pomysł, ponieważ nic nie zaprojektowane do korzystania z regularnych kolekcji będzie z nim pracować.

Przypuszczam, że możliwe byłoby napisanie statycznego analizatora kodu, który mógłby wykryć tego rodzaju rzeczy ... w niektórych przypadkach ... ale to nie jest ściśle "czas kompilacji". Poza tym nie jestem świadomy żadnego istniejącego statycznego analizatora kodu, który robi to "po wyjęciu z pudełka".


Zastanawiam się, czy istnieje powód, dlaczego zrobili to w ten sposób.

Cóż, żaden ze sposobów, w jaki nie może zrobić to naprawdę działa.

Alternatywa # 1:

public interface UnmodifiableList<T> { 
    public T get(int pos); 
    .... 
} 

public interface List<T> extends UnmodifiableList<T> { 
    public void add(T elem); 
    .... 
} 

podczas pisania statyczna może uniemożliwić nam za pomocą niemodyfikowalne listy gdzie wymagany jest jeden modyfikowalny, odwrotna nie jest prawdziwa. Każda lista jest również UnmodifiableList ... i to naprawdę nie ma sensu.

Alternatywa 2:

public interface List <T> { 
    public T get(int pos); 
    public void add(T elem); 
    .... 
} 

public interface UnmodifiableList<T> { 
    // A marker interface 
} 

Teraz statyczne typowanie może uniemożliwić nam za pomocą modyfikowalna lista gdzie wymagany jest umodifiable jeden, ale nie odwrotnie. (To pasuje do twoich wymagań ...) Ponadto klasa implementująca UnmodifiableList nadal dziedziczy operację add i nic nie powstrzyma aplikacji przed próbą jej wywołania.

Podsumowując, systemy typu statycznego nie mogą odpowiednio radzić sobie z tego rodzaju ograniczeniem.

+0

Zastanawiam się, czy był jakiś powód, dla którego zrobili to w ten sposób. :( –

+2

Jako ogólną zasadę należy kodować do interfejsów zamiast rzeczywistych klas uruchomieniowych 'Collections.unmodifiableList' przeznaczony jest w rzeczywistości, aby _force_ Ci kod do interfejsu –

+0

@LouisWasserman -.. I nie sądzę, że to istotne na pytania uzupełniające PO, czyli te, na które odpowiadam –

3

Czy próbowałeś już unModifiableStringList.getClass().getName()?

Dla mnie to daje

java.util.Collections$UnmodifiableRandomAccessList 

które, jak wynika z kodem źródłowym, jest pakiet dostępu statyczny wewnętrzna klasa Collections.

+0

+1 ode mnie ..... –

0

Debug pokazuje, że typ środowiska wykonawczego jest Collections.UnmodifiableRandomAccessList, więc jest to klasa wewnętrzna. Analiza kodu pokazuje również, że może to być Collections.UnmodifiableList.

Nie należy próbować uzyskać dostępu do tej klasy, ma być niezmienna. Spróbuj użyć wspólnego interfejsu, w tym przypadku = Collection.

3

Jest

static class UnmodifiableList<E> extends UnmodifiableCollection<E> 
         implements List<E> 

static class UnmodifiableRandomAccessList<E> extends UnmodifiableList<E> 
             implements RandomAccess 

static class UnmodifiableCollection<E> implements Collection<E>, Serializable 

Jest wewnętrzna klasa Collections, ponieważ Collections nie jest chwilowe i to jest klasa wewnętrzna z widocznością pakiecie, nie może dostęp klasa, a jest to ukrywanie realizacja w OOP.

+0

Jak mogę sprawdzić w moim kodu, czy lista jest niezmienne, czy nie? –

+0

@djaqeel Myślę, że tylko można sprawdzić w czasie wykonywania, ale nie czas kompilacji. Nie zaleca się również sprawdzania w czasie wykonywania. –

Powiązane problemy