Frage zum Interface

[nickname]

Hallo,

eine Sache (und vieles mehr) zum Thema Interface verstehe ich im Mom. nicht so ganz.

Was bringt es mir, ein Objekt einer Klasse dem Typ eines Interface zuzuweisen??

Bsp.:

....
     public class Auto implementes BeliebigesInterface{
   ....
.....
        BeliebigesInterface xyz = new Auto();
    .... usw.

Ich habe nur gelsen, dass es geht aber warum, ist mir schleierhaft

Wäre für Erklärungen dankbar!!!

Danke!!

 

[Wildcard]

Das ist Java Mehrfachvererbung. Hin zum Interface.
Eine ArrayList zum Beispiel ist auch vom Typ List, und Collection und RandomAccess.
In deinem Fall ist Auto vom Typ Auto, vom Typ Object und vom Typ BeliebigesInterface.
Daher funktioniert all das:
[HIGHLIGHT="Java"]BeliebigesInterface x = new Auto();
Auto y = new Auto();
Object z = new Auto();
[/HIGHLIGHT]

 

[0x7F800000]

Solange Autos, Gebäude & Zombies alle das interface "Abknallbar" implementieren, kannst du sie alle gleich behandeln:
[HIGHLIGHT="Java"]
interface Abknallbar{
abknallen();
}

Abknallbar[] verschiedeneSachen={ new Zombie(), new Zombie(), new Auto(), new Gebäude()};
for(Abknallbar x:verschiedeneSachen){
x.abknallen();
}
//zombies zerplatzen
//auto explodiert
//gebäude stürzt ein
[/HIGHLIGHT]
Das tolle ist: du brauchst überhaupt nicht zu wissen, was die einzelnen Klassen konkret machen. Du brauchst nicht mal zu wissen, dass diese Klassen existieren. Wenn in einem Jahr nach der erstellung der Klasse jemand auf die idee kommt, Hubschrauber hinzuzufügen, kann er diese gleich in's spiel reinpacken und abknallen lassen, vorausgesetzt Hubschrauber implementiert auch Abknallbar. Hat ja bei gta ganz gut geklappt^^

 

[Ark]

Ein Interface ist (bei Implementierung) eine Garantie dafür, dass bestimmte Methoden (nämlich genau die im Interface deklarierten) tatsächlich vorhanden und aufrufbar sind. java.lang.Comparable ist ein schönes Beispiel hierfür: Zum Sortieren von Elementen müssen diese miteinander vergleichbar sein. Der Sortierer weiß aber nicht, wie man nun konkret zwei Elemente miteinander vergleicht, deswegen ruft er eine Methode des einen Elements auf, übergibt ihr dabei das andere Element und lässt dann beide unter sich ausmachen, welches nun das größere von beiden ist (falls überhaupt, aber das ist Nebensache).

Die spannende Frage lautet aber: Woher sollte der Sortierer wissen, welche Methode er aufrufen muss? Er kann ja unmöglich alle Klassen kennen. Hier kommt das Interface (=Schnittstelle) ins Spiel: Comparable garantiert, dass eine compareTo()-Methode da ist, die der Sortierer aufrufen kann.

Deine Schuko-Steckdosen kennen ja auch nicht jedes Gerät, dass man an sie anschließen könnte. Du weißt aber beim Kauf eines Geräts "Aha, kann über Schuko-Steckdose mit Strom versorgt werden", und das ist wichtig. Gleicher Fall bei z.B. USB-Schnittstellen: Eine Schnittstelle (=Interface ), die garantiert, dass USB-Geräte an sie angeschlossen werden können. Was für ein Gerät es nun genau ist, ist dabei Nebensache.

Ark

 

[hdi]

Ich versuch's auch mal mit einer Erklärung:
Wenn du ein Objekt mit Typ eines Interfaces deklarierst:

[HIGHLIGHT="Java"]
interface Drivable{
public void drive();
}

class Auto implements Drivable{...}

// nicht:
Auto a = new Auto();
// sondern:
Drivable a = new Auto();[/HIGHLIGHT]

dann kannst du auf diesem Objekt die Methode drive() aufrufen.
Das kannst du jetzt aber auch mit Motorrädern, LKWs, Flugzeugen, und allem anderen
das dieses Interface implementiert.

Das ist aber gar nicht der Vorteil, denn du könntest jeder dieser Klassen die Methode
drive() auch geben ohne Interface.
Der Vorteil ist, dass du diese Objekte abstrahierst: Du wirst nur drive() aufrufen können, und nicht zB getPS() vom Auto oder getKerosin() vom Flugzeug.

An einer Stelle, wo du etwas also nur Fahren willst, und der Rest ist dir egal, nimmst
du Objekte vom Interface-Typ, nicht vom "echten" (Achtung umgangssprachl.) Typ.

Damit ist sichergestellt, dass du keinen Schmarrn machen kannst.

EDIT:

Ein Interface ist eine Schablone. Wenn Auto zwei Interfaces implementiert, das eine
ist Drivable das andere ist zB Verschrottable, dann wird der Schrottplatz alle Autos
als Schrottable-Objekte entgegennehmen, der Chaffeur als Drivable.

Du kannst halt eine Klasse in einem Programmteil, wo du etwas mit Objekten dieser
Klasse tun willst, auf die Funktionalität die du gerade brauchst zusammendrücken.

Wie gesagt: Eine Schablone, die sich über die Klasse legt, und nur ein Loch dort hat,
wo die Interface-Methode steht. Der Rest ist unbekannt.

Vllt noch ein wenig praktisch untermalt, damit der Sinn wirklich klar wird:

Willst du auf einmal dass nur noch Autos Schrottable sind,
und keine Flugzeuge, LKWs, Motorräder, Kühlschränke oder sonst was, dann nimmst
du bei diesen Klassen einfach das Interface raus.
An der Schrottplatz-Klasse muss du gar nix mehr ändern.
Hingegen wenn du es ohne Interface gemacht hättest müsstest du am Schrottplatz
Anpassungen vornehmen, zB die Methoden "überreicheFlugzeug(Flugzeug f)", "überreicheLKW(LKW w)", "überreicheMotorrad(Motarrad m)" usw entfernen.

Mit Interface haste nur "überreicheSchrottable(Schrottable s)", und jetz ist es
dir völlig Wurscht was genau das ist.

Der Code wird also flexibler, du kannst schneller Dinge ändern, erweitern, löschen.

 

[nickname]

Danke an alle!!

Klar, hdi, in einem Interface kann ich ja eine Methode definieren, die von verschieden Klassen genutzt werden kann, das ist mir klar.

Aber eins verstehe ich noch nicht so ganz:

Der Vorteil ist, dass du diese Objekte abstrahierst: Du wirst nur drive() aufrufen können, und nicht zB getPS() vom Auto oder getKerosin() vom Flugzeug.

Meinst du, wenn diese Methoden (z.B. getPS()) auch im Interface stehen?

Danke.

 

[hdi]

Ich hab meinen Post editiert, lies dir den 2.Teil durch dann verstehst du das vllt besser.
Die Methoden getPS() usw. wären natürlich NICHT im Interface, sondern in den jeweiligen
Klassen.
Da die aber nicht interessieren, sollten die auch nicht sichtbar sein.

 

[Wildcard]

Da die aber nicht interessieren, sollten die auch nicht sichtbar sein.

Das ist weniger der Sinn der Interfaces. Bei Interfaces geht es darum, sich auf Schnittstellen zu einigen und nicht auf Typen. Sind an der Modulgrenze nämlich nur Schnittstellen bekannt, kann die gesamte Implementierung ausgetauscht werden, ohne das Konsumenten des Moduls davon betroffen sind.
Aber derartigen Konzepten kann man als Anfänger wohl noch recht wenig anfangen.

 

[hdi]

Naja ich sehe es so, dass Interfaces zwei Vorteile bieten, die voneinander recht
unabhängig sind, und nix miteinander zu tun haben.

1) Design-Planung, oder Wiederverwendbarkeit -> Frameworks
2) in einer ganz konkreten Implementierung

Du hast grad von ersterem geredet, das ist natürlich korrekt.
In meinem Bsp red ich von zweiterem, und das ist finde ich auch korrekt.

Wie gesagt, ich sehe das ziemlich klar getrennt voneinander. In grossen Projekten
wird pauschal für jede Klasse ein Interface geschrieben, und es werden nur Interfaces
in der Implementierung genutzt. (Mit Implementierung mein ich jetz das Modul, das diese Dinge nutzt)

Aber wenn man konkret etwas schreiben will, nutzt man Interfaces auch, nur halt
nicht dafür. Ein Auto kann ruhig ein Auto sein und kein "IAuto" oder sonstwas.
Also Interfaces als Richtlinie dafür, was man mit einem Objekt tun kann und was nicht, einfach um schneller Änderungen
vornehmen zu können und ein Objekt an einer Stelle zu abstrahieren.

 

[nickname]

Hi hdi, deine plastischen Beispiele haben mir echt geholfen, danke!!!

 

[Wildcard]

Also Interfaces als Richtlinie dafür, was man mit einem Objekt tun kann und was nicht, einfach um schneller Änderungen
vornehmen zu können und ein Objekt an einer Stelle zu abstrahieren.

Das deckt sich ja auch hundertprozentig mit dem was ich geschrieben habe. In einem anderen Posting hörte sich das mehr nach fehlgeleiteter Sichtbarkeitssteuerung an.

 

[Leroy42]

das andere ist zB Verschrottable, dann wird der ...

Das nenn' ich mal 'ne kreative Wortschöpfung!