Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
ursprüngliche ArrayList ändert sich bei Übergabe in Methode
Hallo,
Ich habe ein Problem, das mich jetzt schon seit geraumer Zeit beschäftigt. Wenn ich eine ArrayList an eine Methode übergebe und in der Methode ein Element bearbeite, dann ändert sich auch die ursprüngliche Variable.
Java:
import java.util.ArrayList;
public class Main {
static ArrayList<Integer> i = new ArrayList<>();
public static void main(String[] args) {
i.add(0);
System.out.println(i.get(0));
test(i);
System.out.println(i.get(0));
}
private static void test(ArrayList<Integer> i1) {
i1.set(0, 1);
}
}
Die erste Ausgabe ist 0, die zweite 1. Bei jedem anderen Datentyp, den ich getestet habe, ließ sich die Variable so nicht ändern.
Ich würde gerne wissen, wodurch das entsteht und noch wichtiger, wie man es umgehen kann.
Danke im Vorraus
Das passiert in Java bei jedem Objekt, solange das Objekt selbst das nicht verhindert (zB indem es keine Methoden gibt, die das Objekt verändern).
Das liegt daran, dass immer nur eine Referenz auf das Objekt übergeben wird, und in der Methode mit dem selben, nicht nur gleichen, Objekt gearbeitet wird.
In dem ArrayList-Fall müsstest du die Liste zb vorher kopieren, damit in der Methode eine andere genutzt wird.
Java arbeitet mit Call-By-Value.
Wenn du also einen Int übergibst der den Wert 3 hat, dann übergibst du den Wert 3.
Wenn du jetzt Objekte übergibst, dann ist der Wert die Referenz zum Objekt.
Dass heisst, dass das Objekt, welches du übergeben hast, praktisch das Selbe ist.
Wenn du das jetzt unabhängig vom original bearbeiten möchtest musst du zuerst eine Kopie erstellen.
Dafür guckst du dir am besten mal die Methode "clone" an.
Da du anscheinend in der Methode Elemente hinzufügen oder ersetzen willst, musst du eine Kopie der Liste übergeben oder aber in der Methode eine Kopie erstellen und mit dieser arbeiten.
Wenn es sich bei den einzelnen Elemente um änderbare Objekte handelt, dann wirkt sich eine Änderung der Eigenschaften eines Elements auch nach außen hin aus.
Um DAS zu verhindern, musst du Kopien der einzelnen Elemente anlegen (Stichwort "deepclone").
Doch das was du gemacht hast sollte mit jeder Klasse gehen.
Es geht aber nicht mit z. B. int, weil das zwar ein Datentyp ist, aber keine Klasse.
und ArrayList kannst du nur mit Klassen verwenden.
Hier z. B. mit String:
Java:
import java.util.ArrayList;
public class Main {
static ArrayList<String> i = new ArrayList<>();
public static void main(String[] args) {
i.add("Test 0");
System.out.println(i.get(0)); // gibt "Test 0" aus
test(i);
System.out.println(i.get(0)); // gibt "Test 1" aus
}
private static void test(ArrayList<String> i1) {
i1.set(0, "Test 1");
}
}
Du könntest von ArrayList erben und dann die set-Methode unterbinden. Dann gibt es jedes Mal einen Fehler beim Aufruf von set.
Java:
class MyArrayList<E> extends ArrayList<E>
{
public E set(int index, E element)
{
throw new RuntimeException("never use set!");
}
}
Oder du clonest dir die ArrayList (shallow .clone() oder deep copy).
Klassen, welche nicht verändert werden können, heißen immutable (String/Integer/...).
Hmm kannte ich noch nicht. Aber irgendwie macht diese Methode wenig Sinn für mich.
Wenn ich nämlich weiß, dass die aufgerufene Methode meine Liste verändert, dann übergebe ich einfach eine Kopie.
Mir fällt nur sehr wenig ein wo man sowas gebrauchen könnte.
Außerdem verstehe ich nicht, warum die Methode ein Objekt von List zurückgibt. Gibt's hier nicht ne Klasse, welche von List erbt und z.B. UnmodifieableList heißt?
Aber nochmal zurück zur Frage. Ich denke der Fragensteller will eine Methode mit einer ArrayList aufrufen, ohne dass die ArrayList dabei verändert wird. Also muss eine Kopie erstellt werden. clone() wirft aber eine exception beim casten.
Deshalb könnte man es wie folgt lösen:
Java:
test(new ArrayList<Integer>(i));
Dann gibt es keine exception und die aufgerufene Methode kann die ArrayList bearbeiten wie sie will...
Hmm kannte ich noch nicht. Aber irgendwie macht diese Methode wenig Sinn für mich.
Wenn ich nämlich weiß, dass die aufgerufene Methode meine Liste verändert, dann übergebe ich einfach eine Kopie.
Mir fällt nur sehr wenig ein wo man sowas gebrauchen könnte.
Immer dann, wenn du verhindern willst, dass wer auch immer diese Liste bekommt, sie nicht verändert. Oft weißt du nicht, wer sie bekommt, solange nicht die gesamte Code-Basis nur von dir stammt. Meistens bei Rückgaben benutzt, zB bei Gettern.
Außerdem verstehe ich nicht, warum die Methode ein Objekt von List zurückgibt. Gibt's hier nicht ne Klasse, welche von List erbt und z.B. UnmodifieableList heißt?
Sinnvoller wäre es aber andersrum.
Abgesehen von der Benennung beschriebst du nämlich grad die aktuelle Situation, Collections.unmodifieableList gibt eine UnmodifiableList zurück, die Subtyp von List ist
Sinnvoller wäre es aber andersrum.
Abgesehen von der Benennung beschriebst du nämlich grad die aktuelle Situation, Collections.unmodifieableList gibt eine UnmodifiableList zurück, die Subtyp von List ist
Ja genau. UnmodifiableList wäre Subtyp von List, da UnmodifiableList ein Spezialfall von List ist.
Tatsächlich ist es aber so, dass List ein Interface ist...
Also gar keine Erbung von List
Ja genau. UnmodifiableList wäre Subtyp von List, da UnmodifiableList ein Spezialfall von List ist.
Tatsächlich ist es aber so, dass List ein Interface ist...
Deshalb ist UnmodifiableList Subtyp von List, nicht wäre. Ob eins und welches davon ein Interface ist, ist für Sub-/Super-Typ-Beziehung egal.
Rein auf Typ-Ebene wäre es sinnvoller, wenn List ein Subtyp von ImmutableList ist (oder besser MutebleList Subtyp von List), wobei der Supertyp nur Lesenden Zugriff zulässt. Dann lässt sich das ganze auch über den statischen Typ abbilden, nicht nur über de dynamischen.
Deshalb ist UnmodifiableList Subtyp von List, nicht wäre. Ob eins und welches davon ein Interface ist, ist für Sub-/Super-Typ-Beziehung egal.
Rein auf Typ-Ebene wäre es sinnvoller, wenn List ein Subtyp von ImmutableList ist (oder besser MutableList Subtyp von List), wobei der Supertyp nur Lesenden Zugriff zulässt. Dann lässt sich das ganze auch über den statischen Typ abbilden, nicht nur über de dynamischen.
Also soweit ich mich an mein Studium erinnern kann, findet Vererbung nur bei extends statt. Außerdem gibt es Vererbung ja nur bei Klassen und ein Interface ist keine Klasse. https://www.java-tutorial.org/vererbung.html
Gerne lasse ich mich eines besseren belehren...
Mal angenommen List sei eine Klasse und List würde von ImmutableList erben (was du als sinnvoller erachtest).
Zitat:
Sorry das würde absolut kein Sinn machen. List ist die Generalisierung von ImmutableList und MutableList. Deshalb muss List die Basisklasse sein.
Wobei es die Klasse MutableList gar nicht gibt...
Wenn man es machen würde wie du gesagt hast, könnte man sprechen:
MutableList ist eine ImmutableList.
Oder:
Eine veränderbare Liste ist eine unveränderbare Liste.
Es macht keinen Sinn...
Also soweit ich mich an mein Studium erinnern kann, findet Vererbung nur bei extends statt. Außerdem gibt es Vererbung ja nur bei Klassen und ein Interface ist keine Klasse. https://www.java-tutorial.org/vererbung.html
Gerne lasse ich mich eines besseren belehren...
Ich habe nirgends "Vererbung" geschrieben, sondern nur von Subtyp und Supertyp.
Wenn ich Vererbung im Sinne von Java-Vererbung meinen würde, würde ich das auch deutlich schreiben extends gibts btw auch bei Interfaces, interface SubInterface extends SuperInterface.
Sorry das würde absolut kein Sinn machen. List ist die Generalisierung von ImmutableList und MutableList. Deshalb muss List die Basisklasse sein.
Wobei es die Klasse MutableList gar nicht gibt...
Das es ist Listen nicht gibt ist klar, deshalb schrieb ich "wäre sinnvoller".
Ausgehende von ImmutableList ---|> List:
Code:
List list = new ImmutableList();// Wäre zulässig, der statische Typ ist also eine Veränderbare Liste, und der Nutzer weiß nicht, dass die Liste eigentlich Immuteable ist
ImmutableList imList = new List(); // Ginge nicht, ich kann meine muteable List nicht so übergeben, dass der Nutzer sie nicht verändern darf, sondern muss immer auch den dynamischen Typ anpassen
ImmutableList imList = ...;
boolean added = imList.add(42); //Ich kann ganz normal alle Methoden aufrufen, und merke erst zur Laufzeit, dass es schief geht.
Und dann im Gegensatz dazu das ganze andersrum (Immutable mal zu Readonly geändert, das passt besser), List ---|> ReadonlyList:
Code:
List list = new ReadonlyList();//Ginge nicht. Eine (immutable) ReadonlyList kann ich nicht einfach als (mutable) List benutzen
ReadonlyList list = new List(); // Jede veränderliche Liste kann ich genauso nutzen wie eine unveränderliche - nämlich nur lesend und nicht verändernd
ReadonlyList list = ...;
boolean added = list.add(42); //Geht nicht, ReadonlyList böte keine Methoden zum addieren an
List mutList = ...;
boolean added = list.add(42); //Ginge, nur List bietet Methoden zum ändern an
Also: der Compiler lässt Änderungen an der Liste nur zu, wenn es explizit eine List ist. Ist es nur eine ReadonlyList, sind keine Änderungen möglich. Ich kann aber allem, was eine Liste nicht verändern will (also als statischen Typ ReadonlyList hat), jede Liste zuweisen.
Im Vergleich zu der aktuellen Variante:
Der Compiler hat keine Prüfmöglichkeit, deshalb kann ich über egal welchen statischen Typ immer die Liste ändern (was u.U. dann zur Laufzeit explodiert). Ich weiß nur in manchen Fällen schon vorher, dass es zur Laufzeit explodiert (nämlich dann, wenn es als ImmutableList deklarier ist), bekomm dabei aber keinerlei Unterstützung seitens IDE, Compiler oder sonstigem, sondern muss es mir merken.
Das Konzept gibts z.B. mit ReadOnlyProperty in JavaFX oder mit List & MutableList in kotlin
Hmm kannte ich noch nicht. Aber irgendwie macht diese Methode wenig Sinn für mich.
Wenn ich nämlich weiß, dass die aufgerufene Methode meine Liste verändert, dann übergebe ich einfach eine Kopie.
Mir fällt nur sehr wenig ein wo man sowas gebrauchen könnte.
Für das in diesem Thread beschriebene Problem ist sie tatsächlich wenig sinnvoll. Er will ja explizit innerhalb der Methode etwa in der Liste ändern (sortieren z.B.), ohne dass es nach außen dringt. Dafür ist ein Kopie unumgänglich.
Die Methode ist sinnvoll als Rückgabetyp, damit man eben KEINE Kopie anlegen muss oder eben um zu verhindern, dass man versehentlich mal was daran ändert, dann wird sofort eine Exception geschmissen.
Java:
public List<String> getResult() {
return Collections.unmodifiableList(Arrays.asList("a", "b", "c")); //Damit jemand das Ergebnis ändern kann, muss er eine Kopie anlegen.
}
//validvalues kann in der Klasse nirgendwo mehr geändert werden
private static Set<EnumType> validValues = Collections.unmodifiableSet(EnumSet.of(EnumType.Value1, EnumType.Value2));
In der jetzigen Implementierung: Ja, ImmutableList public zu machen, wäre sinnlos, da es keine Einschränkung von Methoden über den Typ gibt und man immer erst konvertieren muss.
Würde es aber einen Supertyp "ReadonlyList" von List geben, der nur lesenden Methoden hat, sähe das ganze aber so aus:
Java:
void moh(ReadonlyList list){
//nur lesender Zugriff möglich
}
...
moh(new ArrayList()); //möglich, da ArrayList Subtyp von ReadonlyList
Für das in diesem Thread beschriebene Problem ist sie tatsächlich wenig sinnvoll. Er will ja explizit innerhalb der Methode etwa in der Liste ändern (sortieren z.B.), ohne dass es nach außen dringt. Dafür ist ein Kopie unumgänglich.
Kann er natürlich machen, es bringt nur nichts, falls die Methode niemals die Ursprungsliste verändern darf. So oder so muss er dann in der Ursprungsmethode eine Kopie anlegen.
Nur zum Testen (JUnit z.B.) der Methode ist es sinnvoll dank der Exception bei Schreibzugriff auf die Ursprungsliste.
