Vererbung bei Interfaces - Gut oder schlecht?

[Der schöne Günther]

Ich habe kein konkretes Problem zu lösen. Wir haben zwei verwandte Themen die sich aber eher mit Problemlösungen bzw. Syntax beschäftigen:

• Interfaces und Vererbung
• Interfaces - Multiple Inheritance

Mir geht es um folgendes, sprach-unabhängig: Interfaces erben von anderen Interfaces. Ist das gut oder schlecht?

Stevie führt eigentlich schon eine super Argumentation ins Feld:

Zitat von Stevie:

Klar, bei Interfaces könnte man sich noch vorstellen, dass man 2 verschiedene Interfaces hat, die auch in Kombination vorkommen und man dann natürlich dieses als 1 Interface haben möchte. Läuft aber in meinen Augen dem Single responsibility principle zuwider.

Und selbst wenn, worin läge der Vorteil eines IWalkAndFly Interfaces, was von IWalk und IFly ableitet, wenn ich in meiner Klasse sowohl IWalk als auch IFly implementieren kann und auch sogar die Möglichkeit habe eine IWalk Referenz zu fragen, ob sie auch nen IFly supportet?

Ich finde nun bei mir bsp. in einem View eine Interface-Vererbung (Bild im Anhang): Ein Typ IMeinTyp soll visualisiert werden. Dazu gibt es das Interface IMeinTypAnzeiger mit der Methode displayMeinTyp(IMeinTyp) . Zusätzlich kann man aber eventuell in so einem View noch eine bestimmte Eigenschaft des Typs hervorheben, dafür gibt es das abgeleitete Interface IMeinTypAnzeigerMarkable . Ich finde das spontan gar nicht so übel.

Ich finde das mit dem Beispiel "IReadable / IWritable" oder "IWalkable / IFlyable" nicht nicht mehr erschlagbar, denn ich kann nichts markieren, wenn ich den Typ nicht vorher visualisiert habe. Die Vererbung ist für mich stimmig.

Was sind eure Meinungen?

[himitsu]

Interfaceverergung bringt, meiner Meinung nach, nur etwas, wenn das nachvolgende interface die Funktionen "erzwinkt", welche im Vorgänger enthalten sind.
Also daß das nächte Interface immer automatisch das Erste "einbindet".
> Achtung, wenn das der erste Interface nicht "explizit" in der Klasse eingebunden wurde, dann kann man nicht auf das Erste casten.

Und kann kann ohne Cast im zweiten Interface auf Funktionen des Ersten zugreifen.

Es wird auch gern verwendet, wenn man neue Versionen eines Interfaces einführt, wo diese Interfaces zusammenhängen, welche auf einander aufbauen. (siehe OTA)
Ist ja nicht so, daß die Vererbung nur für den Compiler ist ... man kann den Code damit auch "dokumentieren", also die Abhängikeiten.



Das letzte UND nutze ich gern aus, um bei Property die Getter/Setter vor der Codevervollständigung zu verstecken.
In Interfaces ist ja leider alles public.

Delphi-Quellcode:

type
  IMyIntfIntern = interface
    function Getter: Integer;  // Diese werden von delphis Codevervollständigung nicht angezeigt, wenn es die Funktionen/Property des IMyIntf auflistet,
    procedure Setter(i: Integer);  // obwohl Sie das eigentlich machen sollte, aber ich hoffe die reparieren es nicht (nicht ohne private bei Interfaces zu erlauben).
  end;

  IMyIntf = interface(IMyIntfIntern)
    [GUID]
    property Value: Integer read Getter write Setter;
  end;

[TiGü]

Zitat von himitsu:

Das letzte UND nutze ich gern aus, um bei Property die Getter/Setter vor der Codevervollständigung zu verstecken.
In Interfaces ist ja leider alles public.

Delphi-Quellcode:

type
  IMyIntfIntern = interface
    function Getter: Integer;  // Diese werden von delphis Codevervollständigung nicht angezeigt, wenn es die Funktionen/Property des IMyIntf auflistet,
    procedure Setter(i: Integer);  // obwohl Sie das eigentlich machen sollte, aber ich hoffe die reparieren es nicht (nicht ohne private bei Interfaces zu erlauben).
  end;

  IMyIntf = interface(IMyIntfIntern)
    [GUID]
    property Value: Integer read Getter write Setter;
  end;

Nett gedacht, aber unnötig (zumindest in 2009 und XE3)!
Siehe Anhang:

[himitsu]

Hatte sowas zuerst im TDE benutzt (glaub ich), aber ich dachte ich hätte es im XE3 auch noch gesehn ... könnte aber sein, daß es nur eine alte Erinnerung war.

Nja, wenn man den Code als Dokumentation nutzt, dann kann es immernoch nicht schaden, wenn man Unwichtiges aus dem Blickfeld entfernt, aber das sollte eine Region auch schaffen.

[Stevie]

In den oben zitierten Threads ging es, soweit ich nach einem kurzen Überfliegen mein Gedächtnis auffrischen konnte, um Mehrfachvererbung. Dies ist bei dir nicht der Fall.

Für mich sieht dein Ansatz eher nach dem Decorator aus. Von daher find ich Vererbung in dem Fall sinnig.

[r2c2]

Hm...

- Vererbung sollte man *immer* mit Bedacht einsetzen. Das ist wie ne Kettensäge. Richtig eingesetzt sehr hilfreich. Falsch eingesetzt gefährlich. Wenn man vererbung macht, sollte man einen guten Grund dazu haben.
- Vererbung unter Interfaces ist nicht per se schlimm. Aber sie ist seltenen sinnvoll.
- Häufig ist Vererbung unter Interfaces schlecht, weil sie Klassen, die Interface A implemenmtieren, zwingt, auch Interface B zu implementieren, was rein logisch betrachtet oft nicht nötig oder sinnvoll ist. Deshalb gibt es das Interface Segregation Principle (ISP), das besagt, dass Interfaces getrennt sein sollten. Bob Martin formuliert das so: "Clients sould not be forced to depend on methods that they do not use".
- DAs bringt uns noch zu was ganz anderem: Interfaces sind kein Selbstzweck. Sie sind *nur* dann sinnvoll, wenn es auch Variablen gibt, die mit dem Interface-Typ deklariert werden. Wenn du keine einzige Variable vom Typ IMyFancyInterface hast, sondern nur davon ableitest, ist das Interface schon falsch, weil wertlos. Es ist zusätzlicher Code, den keiner braucht. Ob das in deinem Fall so ist, kann ich nicht beurteilen, aber mir drängt sich diese Befürchtung auf.
- die Beziehung zum Decorator sehe ich momentan nicht

mfg

Christian