Einsatz von Interface

[Sascha Laurent]

Hallo Leute,

ich habe hiermal eine rein theoritische Frage zu Interface.

Okay, ich weiß Interface werden (auch wenn einige hier das als unschön finden) z.B. / u.U. für Mehrverfachvererbung benutzt.

Sollte man aber Interface's auch dann benutzten, wenn man einen abgeschlossenen Datenblock symoblisieren will. Also z.B.

Ich habe einen Datenblock der Beschreibt, wie von wem Daten übertragen wurden. Diese wird als Domain benutzt und werden nicht gespeichert, sondern dienen als eine Header ausschliesslich zu Übertragung.

Dieser Datenblock wird im Programm mehrfach benutzt.

class Header {
        private String username;
        private String shema;

        // Getter / Setter
        ...
}

Würdet Ihr, um einen sauberen Implementierung, dieses als Interface implementieren also

class Header implements IHeader {
        ...
}

und die Funktionen dann wie folgt implementieren

IHeader myfunc(IHeader header)

oder ist

Header myfunc(Header header)

ein sauberer Stiel? Oder wann würdet Ihr Interface (außer Mehrfachvererbung) benutzten?

Danke
Sascha

 

[Michael...]

Was Du da mit Deinem Header bezweckst und was das mit einem Interface zu tun haben soll habe ich nicht wirklich verstanden.

Interfaces werden u.a. dann benutzt wenn man sich nicht auf eine konkrete Klasse festlegen will oder kann. Ein Interface ist einfach eine Implementierungsvorschrift, wenn ein Objekt ein Interface implementiert müssen die vom Interface definierten Methoden implementiert werden. Das hat den Vorteil man muss, wenn man auf solche Objekte zugreift, dessen konkrete Klasse nicht kennen, es reicht das relevante Interface zu kennen.

Manchmal werden Interfaces auch zur Mehrfachvererbung "missbraucht", aber das einzige was dabei "vererbt" wird, sind Methodendeklarationen - ich würde da jetzt nicht von einer echten Vererbung sprechen.

 

[DarkLegend]

Also mal ausgehend von deiner aussage: (Verstehe auch nicht wirklich was du mit dem unten folgenden Code willst)

Ich habe einen Datenblock der Beschreibt, wie von wem Daten übertragen wurden. Diese wird als Domain benutzt und werden nicht gespeichert, sondern dienen als eine Header ausschliesslich zu Übertragung.

Prinzipiell hängt der Einsatz eines Interfaces immer vom deinem Vorhaben ab.
Willst du lediglich eine feste Übertragungsart festlegen, d.h. der Header ist immer gleich, macht ein Interface an dieser Stelle wenig Sinn.
Willst du jedoch beispielsweise mehrere Übertragungsarten anbieten (oder später solche erweitern) macht es Sinn, ein Interface mti allen relevanten Fakten die du übertragen willst zu definieren.
Anschließend können diese dann in unterschiedlichen Formaten übertragen werden, solange sie die Methoden des Interfaces implementieren.

 

[hdi]

Ich geb dir mal noch ein konkretes Bsp dann verstehst du es vllt besser:

Du modellierst ein Lebensmittelgeschäft und du hast Nahrungmittel. Das ist vllt ne abstrakte Klasse mit der abstrakten Methode getKaufpreis(). Du machst nun Klassen für Banane, Apfel usw. Die erben von Nahrungsmittel.Dann hast du eine Kasse, mit einer Methode

abrechnen(Nahrungsmittel[] einkauf);

. Soweit alles okay.

Aber nun soll das Geschäft plötzlich expandieren und auch Fahrräder anbieten. Was tust du nun? Du kannst diese neue Klasse nicht in eine Vererbungshierarchie mit Nahrungsmitteln quetschen weil diese Objekte viel zu unterschiedlich sind. Ein Fahrrad hat keinen Kaloriengehalt und ein Nahrungsmittel hat keine Gangschaltung

D.h. an der Kasse brauchst du nun ne Liste von Nahrungsmitteln und zusätzlich eine Liste von Fahrrädern. D.h. die abrechnen()-Methode muss abgeändert werden.

Wenn du aber ein Interface hast

interface Erwerbbar{
  public double getKaufpreis();
}

kannst du es in beiden Klassen implementieren und an der Kasse verwendest du einfach den Datentyp "Erwerbbar", d.h.

abrechnen(Erwerbbar[] einkauf).

Jetzt können noch tausend noch so unterschiedliche Klassen dazu kommen, solange eine Klasse das Interface implementiert hast du an der Kasse keine Änderung, weil es dir dort egal ist um was es sich handelt - du kannst die Methode getKaufpreis() aufrufen und mehr interessiert dich da auch nicht.

D.h. du hast eine abstraktere Sicht auf Objekte erlangt. Das ist das Ziel beim Programmieren, immer möglichst abstrakt, d.h. allgemeine Datentypen, die immer nur die Methoden zur Verfügung stellen, die an der jeweiligen Stelle im Programm nötig sind - in Bsp der Kasse ist das nur getKaufpreis().

Du brauchst kein Interface solange du
1) alle Objekte in eine einzige Hierarchie packen kannst, denn dann verwendest du einfach überall den Datentyp der Top-Level Vaterklasse und damit sind alle Objekte abgdeckt.
2) du dir sicher bist dass sich daran auch niemals etwas ändern wird

Aber da 1) oft nicht geht, siehe dieses Bsp, und man von 2) sowieso nie ausgehen sollte..

PS: Du kannst dir auch mal meinen Kurs anschauen, siehe Signatur. Teil 22 & Teil 23 behandeln den Sinn von Interfaces und abstrakten Klassen.

 

[Noctarius]

Bitte nutze die Java-, Code-, ...-Tags

Zur Frage:
Generell ist es immer gut Methoden per Interface zu definieren. Immer mehr Frameworks basieren auf dieser Annahme um z.B. mehrere Implementierungen beliebig auszutauschen. Um hier nur die wichtigsten zu nennen Spring (WireByType) und OSGi (Services).
Aber auch in eigenen Projekten kann es schnell vorkommen, dass man nachträglich den Wunsch verspürt eine Implementierung zu tauschen, ohne die alte wegzuschmeißen. Bei uns in der Firma sind das z.B. Berechnungstypen für verschiedene Punktesysteme.

Generell ist bei uns in der Firma die Einigung gekommen nahezu alles zu Interfacezieren (zu mal Eclipse eine geniale Methode kennt: Extract Interface) da auch schnell mal der Wunsch kommen kann Daten in mehreren Formaten zu persistieren, z.B. standardmäßige Speicherung in der Datenbank (per JPA) oder exportieren der Daten (per JAXB). Man könnte beide Annotations in die gleiche Klasse hängen oder man macht ein Interface und 2 Implementierungen dieses.