Interfaces

[icarus2]

Hi

Ich habe die Theorie in meinem Buch schon par mal durchgelesen über Interfaces. Es ist mir zwar klar wie ich solche aufbaue und in einer Klasse implementiere, doch ich sehe nicht wiso diese Interfaces so wichtig sind.

Wenn man nur statische Variabeln und irgendwelche abstrakte Methoden darin definieren kann. Sie bilden ja eine Schnittstelle, aber zu was eigentlich genau?

Mein Problem ist, dass ich nicht genau verstehe, wie ich ein Interface wirksam einsetzen kann. Ich möchte wirklich sehr gerne damit arbeiten und das verstehen, da wie ich gelesen habe Interfaces ein wichtiger Bestandteil sind für aufwändigere Programme.

Könnte mir bitte jemand versuchen das ein wenig zu erläutern, eventuell mit einem kleinen Beispiel?

 

[L-ectron-X]

Mit Interfaces kann man Klassen, die (thematisch) sonst miteinander nichts zu tun haben, Gemeinsamkeiten verpassen.
Sie ersetzen die in C++ so fehlerträchtige Mehrfachvererbung.
Jede Klasse, die vom Typ des Interfaces sein soll, muss dessen Methoden imlementieren. So wird eine Typisierung sicher gestellt.

 

[icarus2]

Was meinst du mit Typisierung? Ich glaube ich habe genau den Punkt nicht verstanden.

Denn die Methoden aus dem Interface muss ich ja eh überschreiben. Also sehe ich nicht was mir diese Methoden bringen, ausser dass sie alle den gleichen Namen und gleiche Typen haben.

 

[hdi]

Sicher nicht das Burner-Bsp, aber was viel geileres ist mir grad nicht eingefallen.
Angenommen du hast diesen Code:

[HIGHLIGHT="Java"]public class ShopRechnung {

private double gesamtBetrag;

public void addHose(Hose h) {
gesamtBetrag += h.getPrice();
}

public void addTShirt(Tshirt s) {
gesamtBetrag += s.getPrice();
}

public void addGuertel(Guertel g) {
gesamtBetrag += g.getPrice();
}

public double getGesamtBetrag() {
return gesamtBetrag;
}

public static void main(String[] args) {
ShopRechnung r = new ShopRechnung();
r.addHose(new Hose());
r.addTShirt(new Tshirt());
r.addGuertel(new Guertel());
System.out.println("Gesamt Betrag ist: " + r.getGesamtBetrag());
}
}

class Hose {

public double getPrice() {
return 79.99;
}
}

class Tshirt {

public double getPrice() {
return 25.90;
}
}

class Guertel {

public double getPrice() {
return 17.95;
}
}[/HIGHLIGHT]

...jetzt möchte ich, dass es keine Gürtel und Hosen mehr im Shop gibt, dafür
aber weiterhin TShirts sowie neue Artikel: Socken, Unterwäsche, Ketten, Uhren.

Ich möchte nun weiterhin, dass man in der ShopRechnung nicht nur neue Artikel
hinzufügen kann, sondern auch welche löschen.

Was machst du nun? Du löscht die add-Methoden für Hose und Gürtel, schreibst
neue add-Methoden für Socken, Unterwäsche, Ketten und Uhren.
Am Ende schreibst du für analog dazu noch die remove-Methoden. Oder?

Leuchtet doch ein, denke ich und du wirst das sicher hinkriegen.

Das gleiche Bsp mit Interface:

[HIGHLIGHT="Java"]public class ShopRechnung {

private double gesamtBetrag;

public void addArtikel(Priceable p) {
gesamtBetrag += p.getPrice();
}

public void removeArtikel(Priceable p) {
gesamtBetrag -= p.getPrice();
}

public double getGesamtBetrag() {
return gesamtBetrag;
}

public static void main(String[] args) {
ShopRechnung r = new ShopRechnung();
r.addArtikel(new Hose());
r.addArtikel(new Guertel());
r.removeArtikel(new Hose());
r.addArtikel(new Tshirt());
System.out.println("Gesamt Betrag ist: " + r.getGesamtBetrag());
}
}

interface Priceable {
public double getPrice();
}

class Hose implements Priceable {

public double getPrice() {
return 79.99;
}
}

class Tshirt implements Priceable {

public double getPrice() {
return 25.90;
}
}

class Guertel implements Priceable {

public double getPrice() {
return 17.95;
}
}
[/HIGHLIGHT]

Was machst du jetzt, wenn du die obigen Anpassungen annehmen willst?
In der ShopRechnung Klasse:Nur die EINE remove-Methode.

...du musst die neuen Klassen erstellen, fertig.

Wenn du dir den Code ansiehst, merkst du: Du kannst anstelle einer Klasse auch
ein Interface als erwarteten Objekt-Typ angeben.
Reinreichen kannst du alles, was dieses Interface implementiert.

An der Stelle, wo dich nur interessiert, wieviel etwas kostet, nämlich in der Rechnung,
kanns dir sowas von egal sein, was das nun ist.
Ob ein Gürtel, Haus, Auto, .... w h a t e v e r.

Alles, was dieses Interface implementiert, wird angenommen.

Hm... war das n gutes Bsp? Ich fürchte nich besonders, es zeigt nich wirklich alle
Stärken von Interfaces.

Aber vllt erahnst du es... Es geht einfach darum ,dass du abstrahierst.
Du kannst Dinge wesentlich schneller ändern usw.

Stell dir vor du willst 53 neue Artikel, und es gibt nicht nur eine Methode
in der Rechnung, die die Kosten anpasst, sondern noch 4 weitere, die sonstige
Infos der ganzen Artikel bearbeiten.

Ohne Interface hockst du erstmal ne Stunde stupide da mit copy& paste.

 

[Noctarius]

Denn die Methoden aus dem Interface muss ich ja eh überschreiben.

Richtig und genau das ist der Punkt. Du zwingst eine Klasse (oder auch eine Subclass) dazu genau diese Methoden zu implementieren. Wenn du also die Klasse in das Interface castest kannst du zu 100% erwarten, dass der Aufrug existiert.

edit @hdi: das ist doch ein gutes Beispiel

 

[hdi]

Mir kommt grad ich hab darüber ja auch mal was in die FAQ geschrieben:

http://www.java-forum.org/java-faq-beitraege/76834-vererbung-und-polymorphie.html

Dort steht zwar wenig zu Interfaces, dafür darüber zu "abstract". Die Kernidee
von beiden Dingen ist eig. die gleiche.

Ich red hier von den abstrakten Methoden. Ob du eine abstrakte Methode
erbst und implementierst oder sie von einem Interface implementierst, ist eben
(fast) das gleiche.

 

[icarus2]

Danke für die Hilfe, professionel und schnell wie immer


Das Beispiel ist nicht schlecht, sondern sehr gut. Hat mir mit den Erklärungen sehr gut geholfen. Ich glaube ich habe jetzt ziemlich gut verstanden, wofür und wie ich Interfaces einsetzen kann.

 

[icarus2]

Nur noch kurz... ich kann das mit dem add zwar anwenden, kenne das aber von der Theorie her noch nicht.

Unter welchem Stichwort oder wo im Inet könnte ich dazu die Theorie finden?

 

[hdi]

Was meinst du jetzt mit "add"?
Die Methode addArtikel? Was verstehst du daran nicht?

 

[Schandro]

was meinst du mit "add"?
Die "addArtikel"-Methode aus dem Codebeispiel oben?

€dit: Selber Inhalt, aber 5 Minuten zu spät. Vorm antworten schreiben sollte man immer nochmal aktualisieren drücken wenn man so lange zum durchlesen braucht^^

 

[hdi]

sry für OT jetzt aber Schandro:

Q: Why is signature this English bad?
A: WTF?

oder ist das irgendwie beabsichtigt? Soll der Witz quasi von einem Islamisten erzählt sein :bahnhof:

 

[icarus2]

Genau. Da mach ich ja add.Klassennamen()

Ich kenne das bis jetzt noch nicht. Wie man es anwedet ist mir klar. Aber was da passiert und wiso man das darf ist mir unklar. So wie es aussieht wird ein Objekt k mit dem new-Operator erzeugt, sodass man Zugriff auf die Klassen-Methoden hat.

 

[hdi]

Du machst nicht add.Klassennamen, du machst Objekt.Methode...
und zwar die Methode addArtikel() des Objekts ShopRechnung.

Googlen nach

- Java statisch / nicht statisch (im Zusammenhang mit Methoden & Objekten)
- Java Punkt-Notation
- Java Objekt

 

[icarus2]

Jup, das ist klar. Sry, ich hab mich völlig falsch ausgedrückt ^^

Ich verstehe die Parameter nicht so ganz. new Hose() zum Beispiel. Und was nachher passiert mit Priceable p.

Da wird ja das Objekt p angelegt, das auf ein Interface verweist oder so ähnlich... da verstehe ich nicht so ganz was genau passiert. Von was ist p das Objekt, des Interfaces?

 

[hdi]

Also...

Da wird die Variable p angelegt, das ist richtig ja. Das ist ja eine lokale Variable
die erstellt wird wenn die Methode betreten wird.

Diese Variable speichert eine Referenz auf ein Objekt. Das ist ja in Java immer so
bei Methoden-Parametern, die nicht primitiv sind. Hat nichts mit Interface zu tun.

Das Objekt, auf das diese Referenz zeigt, ist halt genau das, auf das die Referenz
zeigt die man in die Methode gibt, also mit der man sie aufruft.

Mit was rufst du die Methode auf? Mit einer Hose. Also, um genau zu bleiben:
Mit einer Referenz auf eine Hose. Wie du weisst kann man Methoden
nur mit einem Objekt des selben Datentyps aufrufen, wie die Signatur der Methode
verlangt.

Und wie du siehst, gibt's keinen Fehler. Das heisst:

Bei Interfaces ist es wie bei Vererbung:

class B extends A

dabei ist jede Instanz der Klasse B nun sowohl vom Typ B, als auch vom Typ A.

class B implements A

same thing. Das Objekt ist vom Typ A, und vom Typ B, auch wenn B ein Interface ist,
das is egal.

Das ist ja grad erst der Vorteil, diese Polymorphie.

Es macht keinen Sinn ein Interface zu implementieren, wenn Objekte dieser Klasse
niemals an einer Stelle im Programm als Objekte des Interfaces behandelt werden.

Es ist sehr wichtig, diesen Satz zu verstehen. Solange du auf konkreten
Objekten arbeitest, und überall "Hose h" oder so hinschreibst, bringt es dir nicht
das geringste, dass die Hose jetzt eine Methode über irgendein Interface hat.
Die kannste dann ja gleich in die Hose-Klasse schreiben.

Bringen tut es dir in dem Moment etwas, wo dein Objekt als Typ von diesem Interface
behandelt wird, und nicht als der konkrete Typ, der er ist.

die Methode addArtikel() nimmt keine Hose, sondern ein Priceable.
Weil Hose ein Priceable ist, geht es.

Und würde der Shop ausschliesslich Hosen annehmen, würde dir dieses Interface
nicht den geringsten Vorteil bringen. Sobald du aber mehrere verschiedene konkrete
Objekte hast (mit verschieden meine ich: verschiedene Klassen), kannst du durch
Implementierung über ein Interface diese - eigentlich verschiedenen - Objekte als
gleich behandeln, in diesem Fall sind es alle Priceables. Auch wenn das eine ne Hose ist,
das andere ein Gürtel.

Das ist das, was man unter "abstrahieren" versteht: Reduzieren verschiedener
Objekte auf eine allgemeinere Ebene, um an dieser Stelle im Programm dynamischer zu bleiben.

Was dynamischer heisst, hast du in meinem Bsp gesehen: Du kannste viel schneller
und flexibler Dinge ändern, erweitern, löschen.

Java kann nicht wissen, dass Hose, Gürtel, Jacke, Socken usw alle die Methode
"getPrice()" haben. Es weiss immer nur etwas über ein bestimmtes Objekt, und zwar
das welches grad vorliegt. zB in der addArtikel Methode die Referenz auf das Objekt,
die du übergibst.
Du als Programmierer weisst aber, dass das ihre Gemeinsamkeit ist.
Also schwupps in ein Interface mit der Methode, und im Shop ein Priceable geben.
Java weiss, dass Priceable die Methode getPrice() hat. Es weiss zu dem Zeitpunkt nicht, dass Hose
oder gürtel usw. diese Methode haben, weil sie das Interface implementieren.
Interessiert Java auch nicht, es macht sein Ding und das ist halt nun mal grad
ein einziges Objekt mit einem bestimmten Typ, und alle anderen Klassen die es vllt
gibt sind ausgeblendet.
Aber du nützt aus, dass eine Klasse, die ein
Interface implementiert, von Java auch als Objekt genau diesen Typs gesehen wird.

Hat's :idea: gemacht?

 

[icarus2]

Wow. Jetzt ist mir so einiges klar geworden. Hab den Text par mal durchgelesen und jetzt verstanden.

Ich hatte leider immer mit konkreten Objekten gearbeitet und deswegen hats nie geklappt ^^


Vielen Dank hdi, war eien super Erklärung

 

[Gast2]

Hier hab ich noch ein Beispiel dass so ziemlich üblich und einfach ist


[HIGHLIGHT="Java"]interface Tier {
public void gibLaut();
}[/HIGHLIGHT]



Ein Tier kann einen Laut geben. Jedes Tier gibt zwar einen anderen Laut, aber trotzdem gibt es die allgemeine Regel, dass es einen Laut geben kann.

Wenn wir nun Klassen wie Hund, Katze, Vogel schreiben, so würde dies so aussehen:
[HIGHLIGHT="Java"]class Hund implements Tier {
public void gibLaut() {
System.out.println( "Wau" );
}
}

class Katze implements Tier {
public void gibLaut() {
System.out.println( "Miau" );
}
}

class Vogel implements Tier {
public void gibLaut() {
System.out.println( "Piep" );
}
}[/HIGHLIGHT]



So nun könnte man sich ein Tier-Array anlegen, dass die verschiedene Tiere hält. Dadurch, dass die Schnittstelle bekannt ist, kann man einen Laut geben lassen... egal, welches Tier es ist!
[HIGHLIGHT="Java"]class Zoo {
public static void main( String[] args ) {
Tier[] tiere = new Tier[3];
tiere[0] = new Hund();
tiere[1] = new Katze();
tiere[2] = new Vogel();

for( int i = 0; i < tiere.length; i++ ) {
tiere.gibLaut();
}
}
}[/HIGHLIGHT]



Ich hoffe, ich konnte Dir damit weiterhelfen...

EDIT: Du kannst die Sache jetzt auch beliebig erweitern


z.B. du hast ein Interface Flugobjekt
[HIGHLIGHT="Java"]interface Flugobjekt{
public void gibGeschwindigkeit();
}[/HIGHLIGHT]

dann kannst du eine Klasse Flugzeug machen weil es "fliegen" kann und kannst es auch unserer Klasse Vogel geben weil ein Vogel auch "fliegen" kann...
So ist ein Vogel gleichzeitig ein Tier und ein Flugobjekt("mehrfachvererbung") und kannst es in 2 verschiedenen Kontexte benutzen

 

[Antoras]

Zu dem Thema hätte ich auch noch eine Frage, die mich zwar schon länger beschäftigt, aber zu der ich bisher keine Antwort finden konnte:

Wann benutze ich Schnittstellen und wann abstrakte Klassen?

@SirWayne, hdi
Eure Beispiele verdeutlichen zwar, wofür Schnittstellen gebraucht werden, das gleiche Ergebnis erhält man aber auch mit Vererbung. Ich hab bisher nur Beispiele (wie eure) gefunden, die problemlos mit Vererbung gleichzusetzen sind. Kann mir jemand einen Anwendungsfall zeigen, bei dem ich zwingend ein Interface und keine Abstraktion brauche? Ich kapier einfach den Unterschied zwischen beiden nicht.

 

[hdi]

Vererbung ist generell nicht so toll. Das Problem ist, dass Vererbung zur Compile-Zeit
geschieht und zu stark bindet.
Du kannst eine solche Bindung während der Laufzeit nicht mehr auflösen, und du
bist generell zu undynamisch.
Änderungen in der Superklasse ziehen immer Änderungen in den Unterklassen nach sich,
und das kann einfach recht hässlich werden.

Solange du nicht wirklich einen guten Grund hast, warum du erben willst, solltest du

- Interfaces für Fähigkeiten nutzen (Methoden)
- Komposition für Eigenschaften nutzen (Attribute)

Komposition heisst, dass du nicht sagst, mein Autoreifen IST ein Kreis (Vererbung), sondern
er HAT einen Kreis (Als Attribut).

Dann delegierst du einfach auf diesen Kreis. Delegation heisst:

[HIGHLIGHT="Java"]// in der Klasse Reifen:
public int getRadius(){
// Wird weiter an das Objekt delegiert, das sich darum kümmert.
// Von aussen kriegt man das nicht mit.
return myKreis.getRadius();
}[/HIGHLIGHT]

Das ist dynamischer, denn jetzt kannst du den Kreis zur Laufzeit ersetzen.
Sagen wir mal du hast ein Action-Fun-Rennspiel und es gibt da so ein Pick-Up auf der Strasse, dass dich ausbremsen soll, indem es deine Reifen zu Achtecken macht,
sodass du voll rumhuckelst und kaum noch fahren kannst.

Wenn jetzt Achteck und Kreis beide ein Interface "ReifenPolygon" implementieren,
dann gibst du deiner Reifen-Klasse ein Attribut

[HIGHLIGHT="Java"]private ReifenPolygon myPolygon; // Komposition[/HIGHLIGHT]

und kannst nun während der Laufzeit diese Reifen austauschen:

[HIGHLIGHT="Java"]// Klasse Reifen:
public void setPolygon(ReifenPolygon newPoly){
myPolygon = newPoly;
}[/HIGHLIGHT]

Wenn du dahingegen von ReifenPolygon erben würdest, könntest du das nicht tun.
Denn du kannst während der Laufzeit das nicht mehr genauer spezifizieren, ob das
nun ein Kreis sein soll oder ein Achteck.

Also Vererbung ist ein überbewertetes Mittel in der OO-Programmierung, anfangs war
es so "Wow das is ja geil", aber jetzt weiss man, es gibt Möglichkeiten das ganze
noch viel besser zu gestalten.

 

[Gast2]

Wenn du jetzt aus meinen 2 Inteface Klassen machst kann der Vogel nur von einer Klasse erben und dann funktioniert es nicht mehr.
Ok du könntest es kombinieren 1 abstrakte Klasse z.B. Tier und dann verschiedene Interface... würde auch ohne Probleme gehen
aber inteface sind dynamischer...

 

[hdi]

...noch n kleiner Nachtrag:

Die Fragen, die hier gestellt werden, werden in sog. Design Patterns behandelt.
Das sind einfach Designs, die im Laufe der Zeit von den schlauesten Köpfen entworfen wurde,
und sich auch bewährt haben.

Ich persönlich lese gerade ein absolut geniales Buch darüber, wo man auf jeder
dritten Seite einen "Aha-Effekt" hat.

Hier der Link:

Entwurfsmuster von Kopf bis Fuß: Amazon.de: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Bücher

Lass dich nich von dem Cover abschrecken. Es sieht aus wie ein billiges Schulbuch,
aber das täuscht. Es behandelt das ganze wirklich professionell und vollständig,
nur eben in einem lustigen Stil.

Kauf's dir, und lies es. Schon nach dem ersten Kapitel wirst du viel besser programmieren können.

 

[Gast2]

Java 2 - Designmuster und Zertifizierungswissen

hier wird es auch erklärt...

 

[HannsW]

Wann benutze ich Schnittstellen ..[/b]

Mal ein Beispiel von mir.
Ich benutze für meine Datenbank-anwendungen BTrieve-Funktionen ( Recorbasierte Datenbanken ).
Welches sind nun die Tätigkeiten, die ein Anwender mit seinen Daten ( z.B. Artikel,Personen etc) machen möchte?
- SUchen
-Neuanlegen
-Bearbeiten
-zum nächsten
- einen zurück usw.
Btrieve schreibt und liest die Records in einem DatenPuffer.
in diesen müssen die vom Anwender erfassten Einzelwerte geschrieben werden. Das könnte z.B in einer Funktion screen2DatenPuffer() und aus dem Datenpuffer zum Anwender in datenpuffer2Screen()

Ich weiß nun, DASS ich diese beiden methoden brauche, weiss aber nicht, WIE das genau geht ( das WAS da geht weiß ich ).

Also packe ich diese methoden ins INterface, und implentiere dieses INterface bei allen classen, die mit BTrieve arbeiten wollen.

in den abgeleiteten Klassen schreibe ich diese INterface-Methoden mit den tatsächlichen aktionen. Vergesse ich eine dieser MEthoden, so bekomme ich schon vom Kompiler die Warnung, dass ich etwas vergass. So kann ich wirklich allgemeine Klassen schreiben.

public interface AliasAdapter {[INDENT]void database2Mem();
void mem2Database();
void leer();
[/INDENT]}

public class Alias implements .....,AliasAdapter { //und schon sind die obigen drei methoden bekannt[INDENT]/** und nun kannich soetwas machen **/
public void getNext() {[INDENT]//den nächsten holen
super.getNext();    

//und date aus Puffer extrahieren
database2Mem();
[/INDENT]}
[/INDENT]}

hth :applaus:?
Hanns

 

[Antoras]

Wenn du dahingegen von ReifenPolygon erben würdest, könntest du das nicht tun.

Hä? Das hab ich nicht verstanden. Vererbten Methoden kann ich auch ohne weiteres neue Werte übergeben. Wenn ich den Klassen Kreis und Rechteck die Klasse ReifenPolygon vererbe, dann ist es problemlos möglich die Methode setPolygon() aufzurufen. Der Compiler sucht sich dann doch einfach während der Laufzeit die Methode, aus der Klasse aus, die er benötigt.

Ich persönlich lese gerade ein absolut geniales Buch darüber, wo man auf jeder
dritten Seite einen "Aha-Effekt" hat.

Ich hab mir das mal auf Google-Books angeguckt. Da steht das gleiche drin, wie das was ich schon zwanzig mal in anderen Büchern gelesen hab. Das WIE verstehe ich auch ohne Probleme, nur das WARUM leuchtet mir nicht ein.

Wenn du jetzt aus meinen 2 Inteface Klassen machst kann der Vogel nur von einer Klasse erben und dann funktioniert es nicht mehr.

Ich sehe bei deinem Beispiel nur ein Interface. Und ja, Mehrfachvererbung geht in Java nicht. Aber WARUM geht das nicht?
[HIGHLIGHT="Java"]public abstract class Nummer1 {

abstract void macheWas();

}

public abstract class Nummer2 {

abstract void macheWasAnderes();

}

public class BraucheNummer1UndNummer2 extends Nummer1, Nummer2 {

@Override
void macheWas() { }

@Override
void macheWasAnderes() { }

}[/HIGHLIGHT]
bzw.:
[HIGHLIGHT="Java"]public interface Nummer1 {

void macheWas();

}

public interface Nummer2 {

void macheWasAnderes();

}

public class BraucheNummer1UndNummer2 implements Nummer1, Nummer2 {

@Override
public void macheWas() { }

@Override
public void macheWasAnderes() { }

}[/HIGHLIGHT]
Statt der Mehrfachvererbung (die nicht möglich ist) muss ich mehrere Interfaces implementieren. Wo ist der Unterschied? Das Ergebnis wäre das gleiche.

Vergesse ich eine dieser MEthoden, so bekomme ich schon vom Kompiler die Warnung, dass ich etwas vergass.

Die Fehlermeldung würde ich auch bekommen wenn ich die Methoden vererbe:
[HIGHLIGHT="Java"]public class Alias extends AliasAdapter{

public void getNext() {
super.getNext();
database2Mem();
}

@Override
void database2Mem() { }

@Override
void leer() { }

@Override
void mem2Database() { }

}[/HIGHLIGHT][HIGHLIGHT="Java"]public abstract class AliasAdapter {

abstract void database2Mem();
abstract void mem2Database();
abstract void leer();

}
[/HIGHLIGHT]

 

[hdi]

Hä? Das hab ich nicht verstanden. Vererbten Methoden kann ich auch ohne weiteres neue Werte übergeben. Wenn ich den Klassen Kreis und Rechteck die Klasse ReifenPolygon vererbe, dann ist es problemlos möglich die Methode setPolygon() aufzurufen.

Erstens hab ich da nicht über Interfaces geredet sondern über Komposition.
Wenn ReifenPolygon kein Attribut vom Reifen ist, sondern er davon erbt, ist es
nicht möglich das während der Laufzeit zu ändern.

Aber auch das, was du schilderst, ist mit Vererbung nicht so gut wie mit Interfaces.
Wie könnte die Klasse ReifenPolygon denn aussehen, sodass du einen Kreis und
ein Achteck davon ableiten kannst?

zB das malen: Ein Achteck braucht Eckpunkte, und dann malst du mittels
drawPolygon(). Einen Kresi zeichnest du einfach per drawOval.

Die Eigenschaften, also Attribute, sind nicht wirklich gleich.
Zeig mir mal wie du da eine sinnige paint-Methode schreiben würdest.

...und jetzt nimm noch als weitere Reifenart ein Dreieck hinzu.
Es gibt hier einfach keine Gemeinsamekeiten mehr.

Mit Interfaces sagst du einfach, die Dinger sind ReifenPolygone, und die Klassen
selber können komplett unterschiedlich aufgebaut sein.

Verstehst du, was ich meine? Versuch es mal: Mach ne Klasse ReifenPolygon und
vererb die einem Kreis und einem Achteck, und dann schau mal wie du das codest.

Die paint-Methode würdest du spontan abstrakt machen denke ich, aber wie
sehen die Attribute dieser Klasse aus, wie die Konstruktoren von Kreis/Achteck/Dreieck?

Was wetten, deine ReifenPolygon-Klasse wird total sch*** aussehen, und deine
Klassen, die davon erben, erst Recht.

Und ja, Mehrfachvererbung geht in Java nicht. Aber WARUM geht das nicht?

Diamond problem - Wikipedia, the free encyclopedia

 

[Wildcard]

Es gibt Mehrfachvererbung von Java. Allerdings werden Typen mehrfach vererbt (durch Interfaces) und nicht Implementierungen wie es bei Klassen der Fall wäre.
Warum es nicht mit Klassen geht? Man hat dieses Feature bewusst nicht aufgenommen, da es bei C++ zu großen Schwierigkeiten geführt hat.
In Java wird zum Beispiel sehr häufig equals, toString, hashCode,... überschrieben.
Du erbst nun von zwei Klassen die dies fleißig tun, deine eigene Klasse überschreibt die Methoden allerdings nicht.
Welche Implementierung ist nun die richtige?
Die der ersten, oder die der zweiten Vaterklasse?
Diese Frage stellt sich bei Interfaces nicht mehr und somit ist eine große Fehlerquelle eliminiert.

 

[hdi]

Ja genau, ich weise nochmals auf meinen Link unten im letzten Post hin,
vllt geht der unter.
Aber eig. steht dort auch nicht mehr als das, was Wildcard gerade sagte.

(@Wildcard: Du willst doch nur deine Beiträge pushen 16.500 seit 2004?
Ist das wirklich so? Krank... PS: Nimm mal meine Freundschaftsanfrage an, du Sack )

 

[hdi]

...achso und Antoras, vllt hilft dir noch folgendes:

Ist dir eig. bewusst, WARUM du vererbst? Was willt du denn erreichen?
Du willst doch nur, dass du irgendwo im Programm einen Oberbegriff für ein Objekt
verwenden kannst, oder?

Du weisst du hast verschiedene Reifen-Typen, und jeden Reifen musst du zB
malen können, du musst Kollisionsabfragen darauf machen können, usw.

Du denkst jetzt spontan: Aha, Gemeinsamkeiten! Also Vererbung, und evtl noch
abstrakte Methoden.

Und genau das ist FALSCH. Denn was ist denn gemeinsam? Naja, wie ich sagte:
paint(), checkForCollision(), usw.

Das sind METHODEN. Das sind Features dieser Klasse, das ist das, was du mit einem
Reifen tun kannst.
Und dafür machst ein Interface, mit diesen Methoden.

Aber warum zum Teufel willst du es dir so schwer machen, wieso willst du
versuchen da irgendwie Gemeinsamekeiten in den ATTRIBUTEN der spezifischen
Klassen zu finden?

Was wäre mit nem Kühlschrank als Reifen? Oder einem Heuhaufen?
Warum nicht, ist einfach lustigen Fun-Racing Game.

Und nun? Kühlschrank und Kreis erben von der gleichen Klasse? Na dann mal
viel Spass.

Also verstehste? WArum schaffst du diese Abhängigkeit, du willst doch nur dass
man die gleichen Methoden aufrufen kann, damit du in der Reifen-Klasse
ein Überobjekt hast "ReifenPolygon", und das kannste malen, austauschen,
auf Kollision überprüfen, usw.

Aber kannste doch einfach nur wenn du diesen ganzen Klassen ein Interface
implementierst.

Und dann kann ein Kühlschrank nur die Attribute haben, die Sinn für einen
Kühlschrank machen, und Kreis KOMPLETT ANDERE.
Trotzdem kannste die paint-Methode in beiden implementieren, und weil sie
ein Interface implementieren, ist sichergestellt dass in der Reifen-Klasse
ein paint() immer reibungslos funktioniert.

Warum gemeinsame Attribut erzwingen, wenn doch nur die Methoden
gleich sind? Die MethodenNAMEN gleich sind! Lass doch eine jede Klasse die
Methode implementieren wie sie lustig ist.

...Vererbungwie gesagt erst dann, wenn du weisst: Ich habe jetzt UND AUCH IN ZUKUNFT (!)
ganz ganz sicher nur Objekte, die wirklich gleiche Attribute besitzen.
Dann kannste vererben. Aber wer kann schon in die Zukunft sehen...
Darum nimmt man Interfaces!

Ok?

edit:

Ich hab mir das mal auf Google-Books angeguckt. Da steht das gleiche drin, wie das was ich schon zwanzig mal in anderen Büchern gelesen hab. Das WIE verstehe ich auch ohne Probleme, nur das WARUM leuchtet mir nicht ein.

Und genau das zeigt das von mir empfohlene Buch (sicher nicht als einzigstes) sehr
schön auf.

Es zeigt dir ein Bsp wo einer anfängt etwas mit Vererbung zu implementieren,
funktioniert wunderbar,
aber dann kommt plötzlich eine Änderung in der Spezfikation (siehe Kühlschränke als Reifen...)
und man kann das nicht mehr gerade biegen.

Also glaub nicht, dass dir das Buch nur das WIE aufzeigt. Die Bsp sind echt gut!

Willst du, dass ich dir das Bsp aus dem ersten Kapitel abtippe? Das verdeutlicht
nämlich eben genau das, was ich grad versuch zu sagen. Oder verstehste es jetzt?

 

[Wildcard]

(@Wildcard: Du willst doch nur deine Beiträge pushen 16.500 seit 2004?
Ist das wirklich so? Krank... PS: Nimm mal meine Freundschaftsanfrage an, du Sack )

Nein, ich war nur langsam beim Posten und sah deinen Reply noch nicht. Die Crux an Multitasking, jeder einzelne Task dauert länger

 

[Antoras]

Ah, jetzt wird das alles ein bisschen klarer.

Zu der Mehrfachvererbung:

Das Beispiel mit der Karo-Vererbung war mir schon bekannt. Ich hab mich bei dem was in meinem Buch steht nur falsch interpretiert, weshalb ich gedacht hab, dass man Interfaces weitere Interfaces implementieren kann. Also:
[HIGHLIGHT="Java"]interface Hallo implements Wort { }[/HIGHLIGHT]
Dabei war gemeint:
[HIGHLIGHT="Java"]interface Hallo extends Wort { }[/HIGHLIGHT]
Folglich bin ich mit dem Beispiel der Karo-Vererbung nicht ganz klar gekommen. Denn das Problem der Mehrfachvererbung wäre mit den Interfaces nach wie vor nicht beseitigt worden. Aber ich hab meinen Denkfehler hier jetzt erkannt.


Zu dem Beispiel mit den Reifen:
[HIGHLIGHT="Java"]public class Auto {

public static void main(String[] args) {

ReifenPolygone[] reifenPolygone = new ReifenPolygone[2];
reifenPolygone[0] = new Kreis(100, 100, 50);
reifenPolygone[1] = new Rechteck(50, 50, 100, 30);
}

}[/HIGHLIGHT]
[HIGHLIGHT="Java"]public abstract class ReifenPolygone {

public int xPos;
public int yPos;

public abstract void paint(Graphics g);

}[/HIGHLIGHT]
[HIGHLIGHT="Java"]public class Kreis extends ReifenPolygone {

private int average;

public Kreis(final int xPos, final int yPos, final int average) {
this.xPos = xPos;
this.yPos = yPos;
this.average = average;
}

@Override
public void paint(Graphics g) {
g.drawOval(xPos, yPos, average, average);
}

}[/HIGHLIGHT]
[HIGHLIGHT="Java"]public class Rechteck extends ReifenPolygone {

private int height;
private int width;

public Rechteck(final int xPos, final int yPos, final int height, final int width) {
this.xPos = xPos;
this.yPos = yPos;
this.height = height;
this.width = width;
}

@Override
public void paint(Graphics g) {
g.drawRect(xPos, yPos, height, width);
}

}[/HIGHLIGHT]
Ich glaube, du hast mein Problem mit deinem letzten Post ziemlich gut beschrieben, hdi. Ich will alle Gemeinsamkeiten zusammenfassen, damit ich sie möglichst einfach ansprechen kann. Aber bei meinem Beispiel, wäre es da nicht völlig egal ob ich auf Vererbung oder auf Schnittstellen setze? Sicherlich, ich hätte Probleme bekommen, wenn ich ein Objekt erzeugen möchte, das gemalt werden soll aber keine xPos bzw. yPos hätte. Aber das will ich ja nicht unbedingt.

Mir ist jetzt aber klar, dass das ziemlich unflexibel ist. Denn vielleicht will ich irgendwann ja wirklich mal ein Objekt erzeugen, dass keine xPos bzw. yPos hat. Allerdings bin ich bisher immer davon ausgegangen, dass ich in einen solchen Fall einfach die xPos und yPos in eine weitere abstrakte Klasse setzen kann, die ich eben dann nur den Klasen vererbe, die sie benötigen. Aber dann hätte ich ja wieder das Problem der Mehrfachvererbung gehabt.


Jetzt hab ich auch den Sinn hinter den Schnittstellen verstanden. Das es falsch ist Attribute zu vererben, ebenfalls. Bei den Attributen hab ich bisher zwar immer versucht sie mit Getter- und Setter-Methoden zu übergeben (hab ich irgendwo mal gelsen, dass man das so machen soll), der wirkliche Grund, das Erreichen von Unabhängigkeit und Flexibilität war mir aber nicht klar. Und genau das ist es was man erreichen sollte; hab ich das jetzt richtig verstanden?

 

[hdi]

Denn vielleicht will ich irgendwann ja wirklich mal ein Objekt erzeugen, dass keine xPos bzw. yPos hat.

Entweder das, oder aber es reicht schon wenn das in einer "komischen" Klasse endet,
die unintuitiv ist. Bsp Achteck: Das hat zwar eine xPos und yPos, aber noch 7 weitere:

[HIGHLIGHT="Java"]public class Achteck extends ReifenPolygon{

private Point p2,p3,p4,p5,p6,p7;

public Achteck(Point p1, usw){
super.setXpos(p1.x);
super.setYpos(p1.y);
this.p2 = p2;
// ...
}
}[/HIGHLIGHT]

..ist doch irgendwie schon hässlich, oder? Klar, du kannst das geerbte Attribut
gar nich erst verwenden, dann sieht die Klasse wieder "sauber" aus, aber was war
dann der Sinn der Vererbung?

[HIGHLIGHT="Java"]Aber bei meinem Beispiel, wäre es da nicht völlig egal ob ich auf Vererbung oder auf Schnittstellen setze?[/HIGHLIGHT]
Naja, du hast jetzt n Rechteck aus dem Achteck gemacht.. In diesem Fall sind die geerbten
Attribute wirklich ziemlich nützlich in beiden Klassen. In diesem Beispiel

Das es falsch ist Attribute zu vererben, ebenfalls.

Stop, was redest du? Genau das ist der Sinn von Vererbung! Wenn du Attribut
erben willst,
und nicht ein Verhalten.
Nur eben, dass es in den meisten Fällen nicht so ist, dass du fest mit gemeinsamen
Attributen rechnen kannst.

Bei den Attributen hab ich bisher zwar immer versucht sie mit Getter- und Setter-Methoden zu übergeben

Völlig richtig! Attribut sind in der Oberklasse auch private, und werden in den Unterklassen
per getter und setter genutzt.

Also nochmal: Vererbung = wenn Attribute gleich sind, und sich das niemals ändern wird
Interfaces ansonsten. Und das "ansonsten" trifft nun mal in der Software-Entwicklung
eher zu

Das war jetzt also Vererbung vs. Interfaces.

EDIT: Ich hab vorhin gesagt Vererbung erbst du Attribute und nicht Verhalten.
Soll nicht falsch rüberkommen: Du erbst ja auch die Methoden! Aber du erbst halt
nur, wenn die Implementierung der Methode gleich ist. Abstrakte Methoden und
Interface-Methoden sind so ziemlich das gleiche. Nur, dass du eben erben musst
um an die abstrakte Methode zu kommen, und wir haben ja jetzt gesehen dass
Vererbung shclechter ist als Interfaces zu implementieren.

Nur ein kleines Stückchen aus der Welt des "richtigen Design".
Ich empfehle dir nach wie vor sehr dringend, ein Design Pattern Buch zu lesen.
Denn das hat nicht nur was mit Interfaces zu tun, die Komposition zB hatte ich ja
vorhin auch schon mal kurz angesprochen.

 

[Antoras]

Das war jetzt also Vererbung vs. Interfaces.

Und ich hab es jetzt endlich vollständig verstanden.:idea:

Ich werde also in Zukunft schauen, dass ich der Vererbung möglichst aus dem Weg gehe.

Ich empfehle dir nach wie vor sehr dringend, ein Design Pattern Buch zu lesen.

Das von dir genannte Buch werde ich mir noch mal genauer anschauen. Oder irgend ein anderes. Gibt ja genügend.

Ich kann dir gar nicht genug danken, du hast mich ein ziemliches Stück nach vorne gebracht. Allen anderen, die mir geantwortet haben natürlich auch ein fettes Danke!

 

[hdi]

Ich werde also in Zukunft schauen, dass ich der Vererbung möglichst aus dem Weg gehe.

Ok, aber nicht dass das jetzt falsch rüberkam. Vererbung = Okay!
Jetzt nie wieder ein "extends" zu nutzen wäre sicherlich falsch.
Nur man muss sich im Klaren sein, wie unflexibee und "stark" Vererbung ist.

D.h. vllt sollte man es so ausdrücken:
Du musst Vererbung nicht aus dem Weg gehen, wenn sie sich dir anbietet.
Aber du musst dir überlegen, ob sie sich dir wirklich anbietet, oder ob du nur grad
dran denkst...

 

[Antoras]

Das kam nicht falsch rüber. Ich werde Vererbung nach wie vor nutzen wenn ich einen Anwendungsbereich habe. Aber ansonsten guck ich, dass ich bei den Schnittstellen bleibe.

 

[Gast2]

Nur man muss sich im Klaren sein, wie unflexibee und "stark" Vererbung ist.

Wie gesagt es hat beides seine Vor und Nachteile, darum würde ich das nicht so pauschal sagen... Es kommt auf den Anwendungsbereich an...

Ich sehe bei deinem Beispiel nur ein Interface. Und ja, Mehrfachvererbung geht in Java nicht. Aber WARUM geht das nicht?

besser lesen ...