/ / Zamiennik dla Collections.unmodifiableList (Arrays.asList (…)) [zamknięte] - java, tablice, niezmienność

Zamiennik dla Collections.unmodifiableList (Arrays.asList (…)) [zamknięte] - java, tablice, niezmienność

Kontynuacja pytanie.

potrzebuję statycznie i publicznie przechowywanie danych jako tablice ale nie chcę, żeby ktoś modyfikował moje dane. Potrzebuję tylko umiejętności czytania z tych tablic. Dlatego myślę, że powinienem użyć czegoś takiego stałe tablice które są prezentowane w C ++.

O ile rozumiem Collections.unmodifiableList(Arrays.asList(...)) zapobiega modyfikowaniu listy w czas pracy ale nie w czas kompilacji.

Zrobiłem następującą klasę (kod jest aktualizowany). Chyba jestem nie wymyślać koła na nowo ponieważ nie mogę uzyskać tego samego wyniku przy użyciu unmodifiableList.

/**
* Emulates constant arrays from C++.
*
* @param <E> Type of elements. Has to be immutable type.
*/
public final class ConstArray<E> {

/** Stores elements. */
private final E[] storage;

/**
* Constructs the object.
*
* @param storage   Elements.
*/
public ConstArray(final E[] storage) {
this.storage = storage.clone();
}

/**
* Returns element at {@code idx}.
*
* @param idx   Index of returning element.
* @return      Element at {@code idx}.
*/
public final E get(final int idx) {
return storage[idx];
}
}

The size metoda i niektóre inne metody zostały pominięte.

Przetestowałem klasę i działa.

Parafrazując, jeśli dostarczę swoją bibliotekę iktoś próbuje zmodyfikować moje dane, myślę, że lepiej, gdy natychmiast dowie się, że nie jest to możliwe (moja klasa nie ma metody, aby coś zmodyfikować) i jeśli użyłem unmodifiableList on / ona zauważy tylko awarię programu.

Czym są zalety i wady z tej klasy? Czy jest na to sposób ulepszać ta klasa?

UPD:

Zdecydowałem się skorzystać z porady @Hoopje (zobacz odpowiedzi). Opiera się ona na doświadczeniu, którego nie mam: Jestem tylko początkującym programistą Java.

Odpowiedzi:

2 dla odpowiedzi № 1

Jeśli „wynalezienie koła” nie jest wystarczająco niekorzystne, widzę jedną poważną wadę twojego podejścia:

Arrays.asList i Collections.ummodifiableList powrót List instancje, więc są zintegrowane ze środowiskiem Java Collections. Oznacza to, że możesz łatwo używać ich w ulepszonych pętlach (for (E item : list) { }), jako strumienie (list.stream()), Użyj wszystkiego List metody, przekaż je do metod, które oczekują Collection lub List podklasy itp.

Drobną kwestią jest to, że twoja klasa tworzy kopię tablicy, podczas gdy jedno i drugie Arrays.asList i Collections.ummodifiableList zwracają widoki swoich argumentów, więc nie kopiują tablicy.

Nawiasem mówiąc, tworzenie płytkiej kopii tablicy nie wymaga „magii”: możesz to zrobić

this.storage = storage.clone();

Odpowiedź na UPD1:

Tak, szkoda, że ​​Java nie zapewnia interfejsów dla kolekcji, których nie można modyfikować. Zatem niezmienny List instancje będą miały na przykład add(E) metoda, która po prostu zgłasza wyjątek. Więc nie ma czas kompilacji gwarancja niezmienności.

Jednak w Javadoc dla twojej metody będzieszoczywiście napisz, że zwrócona lista jest niezmienna. A jeśli użytkownik twojej biblioteki przetestuje swoje oprogramowanie, bardzo deterministycznie zobaczy wyjątek i zda sobie sprawę, że popełnił błąd programowy.

I wierzcie mi, użytkownicy twojej biblioteki to zrobiąbardzo cię nienawidzę, jeśli pozbędziesz się możliwości korzystania ze zwróconej listy w interfejsach API opartych na kolekcji, tylko z niewielką zaletą, że nie ma żadnych metod, które wyglądałyby, jakby je zmodyfikowały.