Wie arbeitet man mit Interfaces

[michael p]

Hallo Leute,


Ich muss fürs Studium einen kleinen Aktienticker zusammenbasteln.
Da ich das polymorph lösen wollte, habe ich mir ein Interface geschrieben.
Die Klasse Aktie implementiert das Interface Handelbar. In der Klasse Aktienticker
nehmen die Methoden nur Parameter vom Typ Handelbar an.
Dadurch wird das Interface bei mir sehr groß, da ich alle Methoden
der Klasse Aktie vorher im Interface definieren musste.

Kann ich das irgendwie anders lösen, also
das das Interface nicht mehr alle Methoden von Aktie vordefinieren muss.
Die Methoden in Aktienticker sollen den Parameter aber nicht casten um von Handelbar auf Aktie zu kommen.

also nicht soetwas z.B.:

public void hinzufügen(Handelbar h){

Aktie a=(Aktie)h;

}

Hoffe jemand hat verstanden, was ich meine und kann mir helfen

 

[Marco13]

Die Richtung ist eigentlich umgekehrt: Man definiert die minimale Menge von Methoden, die etwas anbieten muss, um "Handelbar" zu sein. Und die implementiert man dann in "Aktie". Man sollte aber nicht alles, was eine Aktie so von sich aus an Methoden anbietet in ein Interface packen (warum auch immer man das tun sollte).

Um das implementieren der Methoden ommt man nicht drumrum. Man könnte evtl. eine Abstrakte Klasse anbieten, die für alle Methoden "Default"-Implementierungen anbietet, aber ... welche (bzw. wie viele) Methoden sind denn in diesem Interface?

 

[Wildcard]

public void hinzufügen(Handelbar h){

Aktie a=(Aktie)h;

}

Der cast auf 'Aktie' führt das Interface ad absurdum. Genau das darfst du nicht tun.

 

[Gast]

Mach vllt. noch eine Implementierung von Handelbar für Gold, Fonds, Optionsscheine etc.
Dann wird dir vllt. klarer was dein Interface bedeutet.

 

[michael p]

In dem Interface sind alle getter und setter, die Aktie braucht um alle ihre Instanzvariablen zu
initialisieren. Wenn jetzt aber noch soetwas wie Optionen und Zertifikate dazu kommen wird Handelbar ja noch dicker.


Hier z.B. die Ausgabefunktion

public void ausgabe(ArrayList<Handelbar> handel){
		
		for(Handelbar h:handel){
			
			System.out.println(h.getFirma());
			System.out.println(h.getAnzahl());
			System.out.println(String.format("%,.2f Euro", h.getPreis()));
			System.out.println(h.getDatum().getTime());
		}

Wenn Handelbar h die Methode getFirma() nicht kennt, kann sie nicht auf sie zugreifen.
Außerdem muss ich auch viele unwichtige Methoden ins Interface packen. Z.B. eine getter- und setter-Methode in der
einfach nur definiert wird das Einzahl von Aktie "Aktie" und Mehrzahl Aktien ist. Die brauch ich z.B.
für die Eingabe:

"Anzahl der "+handel.getMehrzahl()+" eingeben          : "

.

Um das implementieren der Methoden ommt man nicht drumrum. Man könnte evtl. eine Abstrakte Klasse anbieten, die für alle Methoden "Default"-Implementierungen anbietet, aber ... welche (bzw. wie viele) Methoden sind denn in diesem Interface?

Die Implementierungen sind schon ganz ok. Ob das jetzt in einer abstrakten Klasse oder in einem Interface steht
macht ja keinen wirklichen Unterschied.

Ich dachte dabei eher an getClass(), also dass dann stehen würde h.getClass().getFirma() und dass
die JVM dann erkennen würde, dass h in Wirklichkeit Aktie ist.

Funktioniert aber leider nicht.

 

[SlaterB]

wenn du die Operation getFirma() brauchst, und diese nur in Aktie drin ist,
nicht aber in anderen Handelbaren, dann bringt dir das Interface nichts, dann schreibe gleich Aktie als Parameter,

ganz anders siehts aus, wenn jede Handelbar-Klasse eine toString() Operation implementiert
und sich die ausgabe(ArrayList<Handelbar> handel)-Operation nur darum kümmert,
diese Einzelstrings zusammenzufassen und in die Ausgabe, in eine Datei oder ins Internet zu schreiben,

eine solche Ausgabe einer Liste beliebiger Handelbar-Objekte wäre ohne Interfaces nur schwer möglich, hier liegt ein echter Mehrwert vor

 

[Marco13]

Also... das "getMehrzahl" sieht schon ziemlich seltsam aus. Da könnte man schon drüber nachdenken, sowas zu machen wie
"Anzahl der Anteile "+handelbar+" eingeben : "

Wenn du nicht sagen willst, welche Methoden in diesem Interface schon stehen, kann man kaum noch was dazu sagen. Außer, ganz allgemein: Das interface sollte imho im so schmal wie möglich sein.

 

[michael p]

naja es stehen die getter und setter zu Firma(Name der Firma),Anzahl,Preis pro Aktie und Datum

also

getFirma();
setFirma();
getAnzahl();
setAnzahl();
getPreis();
setPreis();
getDatum();
setDatum();

wäre das schon zu viel?

 

[SlaterB]

jede Operation macht genau dann Sinn, wenn sie in allen implementierenden Klassen auch enthalten ist (und nicht etwa dummy-mäßig ergänzt wird)

je mehr Operationen, desto weniger Klassen kommen vielleicht in Frage, aber das ist kein Problem der Operationen an sich,

fange globaler an: überlege, welche Klassen logisch zu einem Interface zusammenzufassen sind, welche gleich behandelt werden sollen,
und warum, von welchen Standpunkt aus gesehen das Interface benutzt wird

daraus ergeben sich automatisch die möglichen Operationen,
deren Anzahl ist letztlich egal bzw. wird automatisch aus dem Zweck abgeleitet

 

[jPat]

Falls in jeder Klasse eine Firma, eine Anzahl, ein Preis, ein Datum enthalten ist, dann nehm doch eine abstrakte Klasse.

Dein Interface Kannst du dir dan immer noch dazuschreiben...

 

[maki]

Die Implementierungen sind schon ganz ok. Ob das jetzt in einer abstrakten Klasse oder in einem Interface steht
macht ja keinen wirklichen Unterschied.

Doch, es gibt einen Riesenunterschied, ob man eine abstrakte Klasse oder ein Interface benutzt.

Bei Interfaces gibt es Mehrfachvererbung, bei Klassen (auch abstrakten) nicht.

Mit einer Basisklasse drückt man eine sehr starke Beziehung aus: "Ist ein"
Mit einem Interface dagegen ist die Beziehung lockerer, man fügt nur zusätzliche Funktionalität bei.

Man sollte sich genau überlegen, welches der beiden eingesetzt wird, da (abstrakte) Basis Klassen nunmal sehr einschränkend sind.

 

[jPat]

:idea: für die Ausgabe:
Also ein Interface nur für die getter ....

public <T extends GetterInterface> void ausgabe(ArrayList<T> handel){
 for (T k:handel){
  System.println(k.getDatum());
   ...
  }
}

Nun Kannst du dein Getter Interface in die Aktien, optionen ... implementieren und alle ausgeben, ohne dich festzulegen.

Die Setter würde ich in die Klassen direkt einfügen, Da man evtl über den Konstruktor schon einige Unveränderbare Informationen hat (z.b. Name der Firma).

 

[Marco13]

Damit das nicht falsch interpretiert wird: Ich hatte erwähnt, dass du evtl. eine abstrakte Klasse verwenden kannst, wenn die Implementierung des Interfaces "meistens" gleich ist. Das interface sollte man nach wie vor beibehalten! Aber wenn es für das Interface "Handelbar" eben 10 Implementierungen geben kann, die nur inhaltsarme setter/getter haben, kann man die von einer abstrakten Klasse erben lassen, die diese Trivialmethoden implementiert. Und wenn sie später mal noch von etwas anderem erben müssen, kann man immernoch das "extends" wegmachen, und die Methoden dann halt von Hand implementieren. Es wird ja überall nur davon ausgegeangen, dass sie das interface implementieren - und NICHT, dass sie von der abstrakten Klasse erben, die eine Triavialimplementierung des Interfaces anbietet.

Ähnlich wie die Sache mit MouseListener und MouseAdapter. Ihr wißt schon :roll:

Aber ... muss alles, was "Handlebar" ist, auch eine "Firma" haben? Wie ist das bei Gold? Einige der set-Methoden "fühlen sich komisch an". Soll die Firma wirklich über das Interface geändert werden können? Vermutlich sollte sie im Konstruktor der jeweiligen Implementierungen gesetzt, und dann nurnoch gelesen werden können....?! Soll man den Preis von außen festelgen können? (Wäre geil, wenn man das bei Aktien könnte )... Naja. Das sind wohl eher Architekturfragen, die man so "von außen" nicht beantworten kann.....

 

[maki]

Damit das nicht falsch interpretiert wird:

Falls das an mich gerichtet war (falls nicht, tschuldigung das ich mich aufdränge ), ich fand deine Aussage diesbezüglich sehr eindeutig und stimme ihr voll zu:

Um das implementieren der Methoden ommt man nicht drumrum. Man könnte evtl. eine Abstrakte Klasse anbieten, die für alle Methoden "Default"-Implementierungen anbietet, aber ... welche (bzw. wie viele) Methoden sind denn in diesem Interface?

Wollte michael_p nur erklären, dass es nicht egal ist, ob Interface oder abstrakte Klasse.
Interface + abstrakte Klasse mit Defaultimplementierung ist natürlich sehr angenehm und gleichzeitig flexibel.

Collections sind übrigens so aufgebaut.

 

[michael p]

Danke für die vielen Antworten

tschuldigung, dass ich so lange nicht geantwortet habe.




Hab jetzt meinen Prof gefragt, der meinte, dass hier tatsächlich
eher eine abstrakte Klasse passt, da sich die Implementierungen der Methoden
von Klasse zu Klasse kaum bzw. gar nicht unterscheiden. Zudem
funktioniert der ist-ein -Test und ich brauch keine Mehrfachvererbung.

Also hab ich aus dem Interface eine abstrakte Klasse gemacht.

Das was ich aber jetzt überhaupt nicht verstehe ist, wieso
dann das Interface Serializable funktioniert, obwohl überhaupt keine Methoden
drinne sind.

 

[SlaterB]

für Serializable braucht man keine Operationen,
das Interface selber ist alle Information die ausgedrückt werden soll,

das ist eine Markierung, die nur verspricht, dass das Objekt serialisiert werden kann,
groß prüfen kann man es nicht, wenn es nicht hinhaut, gibts ne Exception,
aber ist eine Art Selbstkontrolle

 

[michael p]

ach so danke jetzt hab ichs verstanden