Hi, ich stehe gerade etwas mit Interfaces auf dem Schlauch. Mir ist klar wie Vererbung funktioniert etc. Jetzt wollte ich mich an das Thema Interface dran machen, verstehe aber nicht so recht den Sinn. Ein Interface beinhaltet soweit ich das verstanden habe z.b. nur Signaturen und Konstanten. Zudem kann ich ein Interface erstellen, das von einem anderen Erbt. Aber was genau habe ich denn jetzt davon? Was kann ich damit sinnvoll anfangen und bei welchen Problemstellungen verwende ich sowas. Danke
Klassen sind ja dazu da, daß man Objekte mit ähnlichen Eigenschaften zusammenfasst. Es gibt also z.B. eine Klasse mit Fahrzeugen, davon dann die Objekte meinFahrrad und deinFahrrad und seinMoped ebenso wie dieKarosseDesBundespräsidenten. Üblicherweise muß es aber nicht immer genau derselbe Typ sein, dann hat man eine Hierarchie von Klassen: Basisklasse, davon mehr oder weniger kompliziert abgeleitete Klassen: Fahrzeug als Basis, Fahrrad, Motorrad und Auto als abgeleitete Klassen. Alle Objekte vom Typ Fahrzeug (also auch die abgeleiteten) können weitgehend glerich behandelt werden, z.B. seinMoped.anfahren() oder dieKarosseDesBundespräsidenten.anfahren(). Vollkommen unabhängig davon kann es eine andere Klassenhierarchie geben, z.B. Lebewesen, darin Tiere und Pflanzen, darin dann wieder Gräser... Lebewesen und Fahrzeuge sind jetzt vollkommen fremd zueinander und haben keinerlei Beziehung. Dummerweise kommt es aber auch oft vor, daß ein Objekt jetzt nicht nur zu einem Typ gehört, sondern (aus einem anderen Betrachtungswinkel) Eigenschaften eines anderen Typs hat, der mit einem Fahrzeug oder Lebewesen nicht zu tun hat. Beispiel ist z.B. "serialisierbar" oder "käuflich" oder "esoterisch". Wenn jetzt sowohl Lebewesen als auch Fahrzeuge, die eigentlich nicht verwandt sind, beide serialisierbar sein sollen, dann implementieren sie halt neben ihren eigentlichen Klasseneigenschaften auch noch ein entsprechendes Interface, z.B. die Methode toString(). Wenn irgendwo ein Objekt herumgeistert (Fahrzeug oder Lebewesen oder sonstwas), von dem zumindest bekannt ist, daß es serialisierbar ist, dann kann man dessen Methode toString() aufrufen, um seinen Inhalt als Text zu bekommen. --- In seriösen Sprachen braucht man kein Interface als eigenes Konstrukt, sondern kann jede Klasse von mehreren Basisklassen ableiten; Basisklasse und Interface sind damit prinzipiell gleich. Java braucht es aber, weil man dort nur jeweils von einer Basisklasse ableiten kann. Der Nachteil der Java-Interfaces ist, daß dort kein Code vordefiniert sein kann, der von den Ableitungen genutzt werden kann. Vielmehr muß jede Methode immer wieder komplett neu definiert werden.
Ein Interface beschreibt die Schnittstelle welche für die Interaktion zwischen Implementierender Klasse und nutzender Methode dient. So kannst du eine Methode schreiben welche auf Objekten von Interfacetypen arbeitet, und du musst nicht wissen was die Konkrete Implementierung ist. Auch kann eine Klasse mehrere Interface implementieren, z.B. implementieren die ganzen Streamklassen das Closeable-Interface, man kann also eine generische Methode schreiben, welche Closeables annimt, und kannst mit dieser alle Arten von Streams schließen ohne das alle Streams von einer gemeinsammen Basisklasse ableiten müssen.
Klaus Wachtler schrieb: > In seriösen Sprachen braucht man kein Interface als eigenes Konstrukt, > Java braucht es aber, weil man dort nur jeweils von einer Basisklasse > ableiten kann. In anderen - ebenfalls seriösen - Programmiersprachen haben sich sehr fähige Leute etwas dabei gedacht, dass sowas und Mehrfachvererbung nicht möglich sind ;-) > Der Nachteil der Java-Interfaces ist, daß dort kein Code vordefiniert > sein kann, der von den Ableitungen genutzt werden kann. Was per se einem Interface wiederspricht, deshalb keinen Sinn macht und darum weder unter Java noch unter .NET möglich sind. > Vielmehr muß jede Methode immer wieder komplett neu definiert werden. Aggregation/Fassade? Gruß Markus
Klaus Wachtler schrieb: > Der Nachteil der Java-Interfaces ist, daß dort kein Code vordefiniert > sein kann, der von den Ableitungen genutzt werden kann. Vielmehr muß > jede Methode immer wieder komplett neu definiert werden. Wer in Interfaces Code definieren will, hat nicht verstanden, was ein Interface überhaupt ist.
Markus V. schrieb: > In anderen - ebenfalls seriösen - Programmiersprachen haben sich sehr > fähige Leute etwas dabei gedacht, dass sowas und Mehrfachvererbung nicht > möglich sind ;-) klar, vor allem wohl "das macht es nur kompliziert" Ich zumindest arbeite häufig mit Mehrfachableitungen - in komplexen Situationen sind die durchaus nicht so exotisch. Und ja, meistens erbt eine Klasse von mehreren Basisklassen etwas vordefiniertes, was sie überschreiben kann, aber nicht muß. Zugegebenermaßen ist das nur in einem kleinen Teil der Klassen der Fall. Aber wenn man eine solche Ausdrucksmöglichkeit nicht immer braucht, sondern gelegentlich, spricht es ja nicht dagegen die Möglichkeit zu haben. Wenn ich den Fall habe, daß ich nur ein Interface erbe und komplett selbst implementiere, dann ist das halt eine abstrakte Basisklasse. Das kann sinnvoll sein, muß es aber nicht - in Java ist man aber dazu gezwungen, weil es genau eine Basisklasse gibt. Markus V. schrieb: >> Der Nachteil der Java-Interfaces ist, daß dort kein Code vordefiniert >> sein kann, der von den Ableitungen genutzt werden kann. > > Was per se einem Interface wiederspricht, deshalb keinen Sinn macht und > darum weder unter Java noch unter .NET möglich sind. hm, und wenn es bei mir doch manchmal Sinn macht? Man muß nicht jeden Mangel als tolles Feature verkaufen :-) Markus V. schrieb: > Aggregation/Fassade? Wenn ein Objekt sowohl A ist als auch B, wieso sollte ich dann B als Aggregation einbauen? Nur weil es schon ein A ist und das Objekt nur eines sein kann?
Martin schrieb: > Wer in Interfaces Code definieren will, hat nicht verstanden, was ein > Interface überhaupt ist. In dem, was du Interface nennst, steht halt kein Code. Es gibt aber auch Fälle, wo welcher sinnvollerweise stehen kann. Das muß man dann nicht Interface nennen, sondern ist dann eben eine Basisklasse. Worauf ich hinaus will ist: Wenn man Mehrfachvererbung zur Verfügung hat, dann ist ein Interface halt nur ein Spezialfall davon, daß man eine (dann leere) Basisklasse beerbt. M.a.W.: Mehrfachvererbung ist eine Erweiterung des Interfaces.
Okay, aber was bringt mir das jetzt im Prinzip, wenn ich alle Methoden jedes mal neu definieren muss? Oder gibt es da einen "Zusammenhang" ? Wenn ich mir das Interface Iterable ansehe, dann finde ich da ein paar Signaturen und muss mich "daran" halten und mir daraus Methoden bauen. Aber was ist der Sinn dahinter, außer dass ich weiß, dass die gleichen Signaturen für andere Klassen auch existieren?
Der Vorteil ist, daß an anderer Stelle z.B. ein Parameter vom Typ Iterable genutzt werden kann. Dann ist egal, ob das aktuelle Objekt ein Auto oder Hornochse oder sonstwas ist, wichtig ist nur daß man darüber iterieren kann. Die Gewähr dafür bekommt man dadurch, daß es das Interface implementiert hat. Daß alle Methoden dafür immer neu implementiert werden müssen, ist ja sinnvoll, habe ich heute gelernt :-)
Was letztlich dahinter steckt, ist die Tatsache, daß man die Welt nicht immer in einer eindeutigen Hierarchie abbilden kann. In einfachen Fällen sieht das noch nett aus, aber letztlich kommt es immer vor, daß je nach Blickpunkt auch andere "Ableitungen" oder etwas ähnliches nötig ist, wie eben "serialisierbar", "iterierbar". Und damit kommt man mit dem einfachen Modell "B leitet von A ab, B1 und B2 von B..." nicht mehr aus, sondern braucht einen Mechanismus, um Beziehungen aus mehreren Richtungen zu verknüpfen. Interfaces sind eine Form davon, Mehrfachableitungen halt eine andere.
Ahhhh!!! Also korrigiert mich wenns falsch ist aber ich mache ein Beispiel. Ich habe zwei Klassen In der einen wird ein String abgespeichert, mithilfe einer Variable String test. In der anderen Klasse habe ich einen String in einem Array gespeichert, also char Array[20] Dann habe ich mir ein Interface gebastelt, mit der Signatur String getString(); Beide Klassen implementieren das und in der jeweiligen Klasse, definiere ich, dass entweder einfach der String zurückgegeben wird, oder das Array erst zu einem String umgebaut wird und dann zurückgegeben wird. Und dann kann ich einfach mein Objekt aufrufen, und habe für beide die Möglichkeit den String über Meinobjekt.getString(); zu bekommen. Stimmt das?
Ja, im Prinzip schon. Dazu müsstest du ein Interface machen, z.B. hasGetString mit der Methode getString. Wenn jetzt beide Klassen (A und B) jeweils das Interface implementieren, kann überall als Parameter o.ä. ein hasGetString herumlungern, für das man getString() aufrufen kann. Dabei ist egal, ob dieses Objekt ein A oder ein B oder etwas davon abgeleitetes ist, oder etwas ganz anderes, was hasGetString implementiert.
Dann macht das ganze endlich mal einen Sinn. Sehe ich das richtig, dass ArrayList<E> Iterable implementiert? Denn ich kann dort liste.iterator() aufrufen und das gleiche mit der Methode iterator() habe ich aber auch bei etwas anderem auch schonmal gesehen.
Mike Mike schrieb: > Sehe ich das richtig, dass ArrayList<E> Iterable implementiert? http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList.html http://docs.oracle.com/javase/6/docs/api/java/lang/Iterable.html Bei Klassen siehe: All Implemented Interfaces Bei Interfaces siehe: All Known Implementing Classes
Klaus Wachtler schrieb: > In seriösen Sprachen Wenn seriöse Sprachen diejenigen Sprachen sind, an die man nur seriöse Programmierer lassen sollte, dann bin ich ja fast geneigt dir zuzustimmen. Angefangen von der Speicherverwaltung bis hin zu sonstwas wird dem Javaprogrammierer etliches an Arbeit, Entscheidungen und Kontrolle abgenommen. Meist ist es recht praktisch, manchmal ist es etwas störend und bevormundend. Wenn derjenige, der die Klassenhierarchie entwirft, Java gewohnt ist, dann wird es nur recht selten dazu kommen, dass ihm die Mehrfachvererbung wirklich abgeht. Wenn man aber die Mehrfachvererbung gewohnt ist, so ist es natürlich ein Graus, wenn man dieses Werkzeug plötzlich verliert. Java deswegen als unseriös zu bezeichnen halte ich aber für deplatziert, es sei denn man will einen Popcornüberschuß abbauen.
horst schrieb: > Wenn derjenige, der die Klassenhierarchie entwirft, Java gewohnt ist, > dann wird es nur recht selten dazu kommen, dass ihm die > Mehrfachvererbung wirklich abgeht. Wenn man es nicht anders kennt, nimmt man halt für alles ein Interface, und muß dann alles immer wieder neu implementieren - egal ob es sinnvoll ist oder nicht, worüber sich der Doppel-Mike ja schon gewundert hatte. Aber du hast recht: wer von Geburt an blind ist, vermisst Farben wohl nicht so sehr. > ... > Java deswegen als unseriös zu bezeichnen halte ich aber für deplatziert, > es sei denn man will einen Popcornüberschuß abbauen. Willst du etwa unterstellen, ich würde provozieren? Das trifft mich jetzt hart!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.