Array und List

[manja]

irgenwie kann ich nicht begreifen: wo ist den Unterschied?
In Array - Objekten einen Typen in List - nicht?
Kann vielleich jmd erklären?

 

[Thomas Darimont]

Hallo!

Also Arrays sind in java etwas "primitiver" als allgemeine Collectiontypen wie List etc...

Arrays sind durch die deklaration von vornherein getypt sprich, wenn du schreibst:

int[] arr = new int[1000];
// ....

und du greifst aufs 10 element zu weist du immer genau, dass es sich um das zurückgegebene Element um einen int Wert handelt.

int i = arr[77];
...
Du kannst ein Array aber auch vom Typ Object deklarieren 

Object[] objArr = new Object[100];

du könntest nun sagen 

objArr[11] = new Integer(100);
objArr[12] = "Hallo";
objArr[13] = new Vector(2);

... etc,....

hier haben wir nun streng genommen wieder ein getyptes Array welches jedoch beliebige Objekttypen aufnehmen kann. Da in Java alle Klassen implizit von Object abgeleitet sind und Object somit den kleinsten gemeinsamen nenner darstellt hat man hier ein nettes Konstrukt um beliebige Typen in einem Feld zu speichern.

Auf diesem Prinzip setzen auch alle Collection Typen auf die ihre Daten intern in Object Arrays verwalten und so eine generische Speichermöglichkeit anbieten. In Collections wie List kannst du nur Object Typen verwenden. Primitive Typen wie (int, byte, short, long, double, float, char, boolean) musst du in die entsprechenden Wrapperkonstrukte eintüten ....

Ich denke man könnte auch sagen das die primitiven Arrays ein wenig flotter als ihre "Kollegen" sind, da diese leichter auf native Speicherstrukturen abgebildet werden können.

HTH.

Gruß Tom

 

[Snape]

Original geschrieben von manja
irgenwie kann ich nicht begreifen: wo ist den Unterschied?
In Array - Objekten einen Typen in List - nicht?
Kann vielleich jmd erklären?

Der Vorteril/Nachteil von Collections ist, dass sie dynamisch größer werden können, während für Arrays beim Anlegen die Größe angegeben werden muss.
In Collections kann man fröhlich nach und nach mit add(...) Objekte hinzufügen, bei Arrays geht das nicht. Das ist ein Vorteil, aber auch ein Nachteil. Denn in Java wird beim Erstellen einer Collection natürlich dennoch initial ein gewisser Speicherraum alloziiert. Wenn die Collection so klein ist, dass der Speicher bei weitem zu groß ist, werden also Resourcen verschwendet. Ebenso, wenn das initiale Volumen überschritten wird, vergrößert sich die Collection um die initiale Größe und der eben erwähnte Nachteil könnte wieder eintreten.
Also angenommen, für ein ArrayList list = new ArrayList(); wird Speicher für 10 Objekte alloziiert. Nun füge ich ein Objekt nach dem anderen hinzu, bis ich ein elftes Objekt anfüge. Dann vergrößert Java intern den Speicher um Platz für weitere 10 Objekte. Wenn ich nur 11 Objekte habe, liegt der erhöhte Resourcenverbrauch offenbar auf der Hand.

Ich hoffe, ich verwechsel das nicht mit der Funktionalität der HashMap...

Naja, wenigstens kann man Collections bequem sortieren (lassen) via Collections.sort(myCollection);
Notfalls, indem man seine eigenen Sortierregeln in einem eigenen Comparator definiert... (falls die Objekte in der Collection nicht vom Typ Comparable sind)

 

[Patrick Kamin]

-

Es besteht ja aber immer noch die Möglichkeit sich selber eine dynamische Liste zuprogrammieren, dann kann man sicher sein, dass auch nur so viel Speicherplatz verwendet wird, wie wirklich benötigt wird.
Gruß

 

[Thomas Darimont]

Hallo!

Ich hoffe, ich verwechsel das nicht mit der Funktionalität der HashMap...

Die Hashmap macht das ein wneig anders:

An instance of HashMap has two parameters that affect its performance: initial capacity and load factor. The capacity is the number of buckets in the hash table, and the initial capacity is simply the capacity at the time the hash table is created. The load factor is a measure of how full the hash table is allowed to get before its capacity is automatically increased. When the number of entries in the hash table exceeds the product of the load factor and the current capacity, the capacity is roughly doubled by calling the rehash method.

As a general rule, the default load factor (.75) offers a good tradeoff between time and space costs. Higher values decrease the space overhead but increase the lookup cost (reflected in most of the operations of the HashMap class, including get and put). The expected number of entries in the map and its load factor should be taken into account when setting its initial capacity, so as to minimize the number of rehash operations. If the initial capacity is greater than the maximum number of entries divided by the load factor, no rehash operations will ever occur.

Gruß Tom

 

[Christian Fein]

Re: -

Original geschrieben von Patrick Kamin
Es besteht ja aber immer noch die Möglichkeit sich selber eine dynamische Liste zuprogrammieren, dann kann man sicher sein, dass auch nur so viel Speicherplatz verwendet wird, wie wirklich benötigt wird.
Gruß

Ja nur ist dies mit Kanonen auf Spatzen geschossen.
Wenn ich Speicher für 9 Objecte zuviel habe, dann entscheiden die Objecte in welchen Grössenvorstellungen wir uns bewegen.
Ein Object das 100kb Speicherverbrauch benötigt, frist mir also dann 900 kb Speicher zuviel auf. Wenn ich Objecte mit 100 kb habe, ist in meinem Design / Planungsphase etwas falsch gelaufen.

Eine dynamische Liste programmieren, ist eine tolle Sache um das verständniss für selbsallozierende Objecte zu bekommen, aber normalerweise ein schlechter Rat.
(mannche) Listen sind Threadsicher und bieten andere wichtigen Dinge, die hundertprozentig funktioneren, gedebugged, stabil sind. Jedes Stück Code das mann selber Implementieren muss, macht eine Anwendung instabiler und komplizierter.
Keep it simple, stupid

Ich mag da lieber die faule Variante,
ahhh ge das passt scho

 

[Patrick Kamin]

-

Hallo...

Wenn ich eine Datenstruktur benötige, in der sich häufig die Reihenfolge ändert, sprich, Daten werden mittig hinzugefügt oder gelöscht, dann ist eine Liste doch dafür am besten geeignet, allein schon um die wilde Rumkopierei auf einem Array zu vermeiden.

Jedes Stück Code das mann selber Implementieren muss, macht eine Anwendung instabiler und komplizierter.

Dann sollte man heutzutage vielleicht gänzlich auf die Programmierung verzichten - oder man bleibt bei Lisp-Scripts für den Emacs, da kann man auch nicht viel kaputt machen