Collections, Objektsammlungen, Interfaces,...HIlfe!

J4V4-G1MP

Grünschnabel
Hallo zusammen,

in meiner Lernlektüre bin ich jetzt bei der Collection-API angelangt und verstehe, selbst nach dem zehnten Durchlesen, überhaupt nichts mehr.

Wofür sind denn all diese Interfaces gut, die von einander erben, aber nur abstrakte Methoden enthalten können, die ja nicht mal eine Implementierung haben?

Das heißt doch, dass ich die alle noch übernehmen und implementieren müsste, oder?
Und was genau kann ich damit überhaupt anfangen? Hier stehen die Methoden von List und Collection aufgelistet, aber kein Bezug zu irgendeiner realen Problematik.

Diese ganzen abstrakten Klassen machen einander Vorgaben, aber was hat man am Ende davon?

Ich weiß überhaupt nicht, was ich damit machen soll. Was ist denn ein Interface mehr als eine Schablone von unimplementierten Methoden, die erbenden oder implementierenden Klassen vorgeben, was sie zu überschreiben haben?

Ich verstehe nichts mehr, aber ich will nicht aufgeben. Bitte helft mir!
 
Ich gehe mal davon aus, dass du bereits den Umgang mit Klassen und Objekten gelernt hast. Im Normalfall läuft das so ab, dass man irgendwelche Klassen deklariert und bei bedarf dann durch abgeleitete Klassen erweitert, etwa um neue oder veränderte Funktionalitäten. Soweit ist das alles ja kein Problem. Jetzt kommen aber noch abstrakte Klasse dazu. Das sind, wie du schon richtig erwähnt hast, nur abstrakte deklarationen, die den ableitenden Klassen vorgeben, was diese implementieren müssen. In den abstrakten Klassen lassen sich aber die Methoden auch konkret implementieren, somit hat man dann quasi eine gewisse Basisfunktionalität, die nicht immer neu implementiert werden muss. Andere Methoden aber schon, weil die in der Form vielleicht noch gar nicht implementiert werden können, weil noch gar nicht klar ist, wie die Methode arbeiten soll.

Mal ein Beispiel: Nehmen wir mal den USB Anschluss. Es ist ein Anschluss, aber man kann so viele Geräte damit anschließen, Mäuse, Tastaturen, Headsets und was weiß ich was noch alles. So, man könnte also eine abstrakte Klasse UsbDevice deklarieren, die entsprechend Methoden für den Datentransfer bereitstellt. Wie das Gerät aber arbeitet, kann man im Vorfeld nicht sagen, man weiß es ja nicht. Man muss also irgendwie sicherstellen, dass man alle Geräte ansprechen kann ohne zu wissen, wie sie "funktionieren" und das geht nur, wenn alle Geräte die selben Methoden besitzen. Und genau dafür sorgen abstrakte Klassen und Interfaces. Der Unterschied ist nur, dass man in Java nur von einer Klasse gleichzeitig erben kann. Wenn man also noch weitere Methoden-"Standards" einpflegen möchte, dann müsste man die Vererbungshierarchie aufbrechen, denn anders wäre das nicht möglich. Deswegen sind Interfaces eingeführt worden. Es lassen sich beliebig viele Interfaces von einer Klasse implementieren und somit Methoden vorgeben. Dadurch ist eben sichergestellt, dass die Klasse eben genau die Methoden auch tatsächlich implementiert, man wird dazu gezwungen.

Ich weiß nicht, wie ich das sonst noch erklären soll. Interface heißt Schnittstelle und genau so kann man sich das auch vorstellen. Es ist egal, was hinter der Schnittstelle genau geschieht, das ist das Problem des jeweiligen Gerätes oder Moduls, aber die Schnittstelle selbst muss klar definiert sein, damit diese von allen gleich genutzt werden kann. Stellt dir mal vor, jeder Hersteller würde seine Geräte alle mit irgendwelchen willkührlichen Schnittstellen ausliefern, das wäre das pure Chaos. Und beim Programmieren ist das auch nicht anders.

Da du das im Zusammenhang mit Collections erwähnt hast. Jede Klasse, die das Interface List implementiert, muss z.B. die Methoden add, get, remove, iterator und einige andere implementieren. Damit soll einfach sichergestellt werden, dass alle Listen auf die gleiche Weise angesprochen werden können und nicht jeder irgendwie was anderes macht. Gleichzeitig ist es aber Sinn und Zweck jeder einzelnen Liste, dass sie unterschiedlich arbeiten. Einige arbeiten mit Array, andere mit Ketten, wieder andere können sortiert werden und wieder andere machen etwas völlig anderes. Aber alle können gleich angesprochen werden. Du kannst es auch als eine Standartisierung oder sowas sehen.
 
Zuletzt bearbeitet:
Besser hätte man es nicht erklären können. Danke Akeshihiro!

So langsam blicke ich doch durch. In meinem Lernheft wird man mit den Klassen Collection und seinen Methoden, List inkl. Methoden und Map mit Methoden zugeschmissen. Dazu werden ein paar Sätze gesagt. Was du erklärt hast, hatte ich im Prinzip schon gelernt, aber es fehlte die Brücke zu diesen Objektsammlungen.

Vielen Dank!
 
Das heißt doch, dass ich die alle noch übernehmen und implementieren müsste, oder? Und was genau kann ich damit überhaupt anfangen? Hier stehen die Methoden von List und Collection aufgelistet, aber kein Bezug zu irgendeiner realen Problematik.

Egal. Die Antwort auf obige Frage ist nein. Das Interface List erbt vom Interface Collection. Das Interface Collection gibt die Basismethoden an, die jede implementierende Klasse von List zwingend haben muss, so auch List. Unterhalb vom Interface List kommen auch schon konkrete Klassen wie LinkedList, ArrayList und Vector. Neben List gibt es noch zwei weitere Interfaces Set und Queue, die wiederum ihre konkreten Klassen haben. Insofern liegt schon fast alles fertig implementiert vor. Eine Ausnahme sind die Interfaces Comparable und Comparator, die man selber implementieren muss, wenn man eine sortierte Collection haben will.

Das Interface Collection ist sehr umfangreich und es braucht Zeit, bis man versteht, welches Interface resp. welche Klasse für was gut sein soll. Dieses Bildchen ist eine Entscheidungshilfe, wann welche Klasse eingesetzt werden soll:

java-map-collection-cheat-sheet.jpg

Viel Spass.
 
Zuletzt bearbeitet:
Zurück