Interface imlementieren

[OnDemand]

Hallo zusammen,

ich glaube ich hab im Code was gefunden wo sich bestens ein Interface eignet, dazu aber ein paar Fragen. @KonradN du hast im Thread "cleanCode" so schön zu den Interfaces geantwortet, hast Lust zu antworten?

Aktuell folgendes:

nehmen wir an es gibt 3 CMS systeme an welche Daten aus meiner App geschickt/geholt werden. Für alle 3 Systeme mache ich: Daten holen, Daten senden, Daten löschen, Daten updaten.

Nun habe ich 3 Klassen (Quarzjobs) für jedes CMS eine eigene (weil sich die Implentierung ja unterscheidet, jedes hat ne andere API). Hier wäre doch ein Interface "CMSClientInterface" ideal mit den 4 Methoden send, get, put, delete Meine aktuellen 3 Klassen implementieren dann das Interface.

So was macht das jetzt aber für einen Sinn? Wenn ich eine Funktion erweitere, muss ich das Interface um eine Methode ergänzen. Vielleicht aber brauch ich das nur in CMS2, trotzdem muss ich das in allen InterfaceImpl einbauen, den Methodenbody dann leer lassen? Den einzigen Vorteil den ich sehe ist, dass wenn ich ein neues CMS einbaue und mit dem IF erweitere, dann vergesse ich nicht irgendwelche Funktionen einzubauen.

Freue mich über Feedback

 

[Oneixee5]

Das Interface soll nur die Methodensignaturen bereitstellen, welche immer implementiert werden müssen. Ein Interface könnte auch default Methoden enthalten, diese müssen nicht jedes mal überschrieben werden. Genauso wäre es möglich abstrakte Klassen zu verwenden, die alle Methoden bereitstellen aber die Methoden leer (z.B. in Swing) oder mit einer NotImplementedException implementiert. Dann wäre man nur gezwungen die Methoden zu überschreiben, welche auch genutzt werden. Das wird z.B. bei Collections ( List.of() ) manchmal gemacht, etwa um eine unveränderliche Liste zu erzeugen, die aber trotzdem dem List-Interface entspricht.
Einen Sinn macht das aber m.E. nur, wenn deine Quartz-Jobs so generisch sind, dass sie auch mit verschieden implementierten Interfaces etc. umgehen können. Falls jeder Quartz-Jobs sowieso eine spezielle Implementierung hat dann erzeugst du einfach nur zusätzliche Komplexität.

 

[OnDemand]

Danke! Auf jeden Fall hat jeder Quartz Job 5 Methoden die in jedem Job gleich sind. Dies sind Methoden welche die Daten aus der db holen und dann an die CM/S weiter gibt.

Diese 5 Methoden machen in jedem Job exakt das gleiche, die kann ich also schon mal auslagern

 

[Robert Zenz]

Nun habe ich 3 Klassen (Quarzjobs) für jedes CMS eine eigene (weil sich die Implentierung ja unterscheidet, jedes hat ne andere API). Hier wäre doch ein Interface "CMSClientInterface" ideal mit den 4 Methoden send, get, put, delete Meine aktuellen 3 Klassen implementieren dann das Interface.

Das klingt, spontan, nach zu spezifischen Methoden fuer die Schnittstelle. Du willst eigentlich immer relativ vereinfachte Methoden bereitstellen komplett ohne Implementierungsdetails, so dass du nie in die Verlegenheit kommst dass die Schnittstelle angepasst werden muss, weil sich eine konkrete Implementierung aendert. Denke da mehr in Arbeitsablaeufen, also in konkreten Handlungen.

So was macht das jetzt aber für einen Sinn?

Der Sinn ist dass der verwendende Code drei unterschiedliche, fremde Systeme anfragen kann ohne das man diesen aendern muss,

for (DataProvider dataProvider : registeredDataProviders) {
    Data data = dataProvider.fetchData();
    backend.save(data);
}

Da spielt es jetzt keine Rolle ob ich einen oder hunderte Quellen habe, ob diese einmal einen REST-API im Internet abfragen oder eine 3,5" Diskette ueber einen Praktikanten der das Ding mit einem Messgeraet ausliest.

Wenn ich eine Funktion erweitere, muss ich das Interface um eine Methode ergänzen. Vielleicht aber brauch ich das nur in CMS2, trotzdem muss ich das in allen InterfaceImpl einbauen, den Methodenbody dann leer lassen?

Zum Beispiel. Eine andere Moeglichkeit sind Erweiterungen wie sie Eclipse verwendet:

public interface DataProvider {
    public Data fetchData();
}

public interface DataProviderBetterDataExtension {
    public BetterData fetchBetterData();
}

public class FirstDataProvider implements DataProvider {
    public Data fetchData() {}
}

public class AnotherDataProvider implements DataProvider, DataProviderBetterDataExtension {
    public Data fetchData() {}
    public BetterData fetchBetterData() {}
}

for (DataProvider dataProvider : registeredDataProviders) {
    Data data = dataProvider.fetchData();
    backend.save(data);

    if (dataProvider instanceof DataProviderBetterDataExtension) {
        BetterData betterData = dataProvider.fetchBetterData();
        backend.save(betterData);
    }
}

Den einzigen Vorteil den ich sehe ist, dass wenn ich ein neues CMS einbaue und mit dem IF erweitere, dann vergesse ich nicht irgendwelche Funktionen einzubauen.

Ja, und du musst deine Logik nicht anpassen welche diese Schnittstelle verwendet, obwohl ein weiteres System hinzugekommen ist.

 

[LimDul]

Eine Möglichkeit, wie man zu Interfaces kommen kann, ist rückwärst denken. Sprich, du hast sagen wir mal 3 Implementierungen ohne ein gemeinsames Interface.

Nun möchtest du an einer Stelle etwas gleichartiges mit allen Implementierungen tun ohne instanceof Abfragen einbauen zu müssen oder ähnliches. Dann ist klar für diese Anforderung brauchst du jetzt ein Interface, dass genau diese Methode bereitstellt.


Das ist im Endeffekt auch eine Ideen von Test Driven Development. Du baust da nicht von vornerein Interfaces. Die kommen durchs Refaktoring - weil man Duplizierungen ausbauen will - auf ganz natürliche Weise rein.