Schon wieder: Warum Interfaces

[DeddyH]

Und das hat genau was mit Interfaces zu tun?

[edit] Um noch etwas Konstruktives beizutragen:
- Bei der Verwendung von Interfaces muss keine bestimmte Klassenhierarchie eingehalten werden, da der Verwender lediglich das Interface sieht und nicht die dahinterstehende Klasse.
- Interfaces können modulübergreifend (Anwendung <-> DLL) verwendet werden, im Gegensatz zu Objekten (OK, das ginge mit BPLs, die sind aber versionsabhängig).
- Eine Klasse kann beliebig viele Interfaces implementieren, damit erreicht man so etwas ähnliches wie Mehrfachvererbung.
- Bei Verzicht auf sprachspezifische Typen und/oder Konstrukte können Interfaces sprachunabhängig verwendet werden.

Mehr fällt mir spontan nicht ein, vielleicht meldet sich Stevie ja noch [/edit]

[Jasocul]

Ein Spezialist für Interfaces bin ich sicher nicht und ich nutze die auch nur rudimentär. Aber vielleicht bin ich deshalb der Richtige für das "wieso".
Ich stand auch mal vor dieser Frage und bin auf dieses Beispiel gestoßen.
Natürlich kann man das auch mit einer Basisklasse lösen, die entsprechende abstrakte Methoden verwendet, aber denkt man wirklich von Anfang an, an alle möglichen Dinge?
Es ist sicher möglich, die Basisklasse später zu ergänzen, ist in dem Fall aber gezwungen, auch alle Nachkommen anzupassen. Mit einem Interface kann man das auch einfach in den Nachkommen bei Bedarf machen.

Verwendet habe ich das zum Beispiel bei einer TreeView. Dort wurden viele Objekte eingebunden. Um die Darstellung zu vereinfachen, bekam jedes Objekt ein Interface mit Methoden, die mir eine vernünftige Bezeichnung liefern und bei Bedarf verschiedene Berechnungen machten. Durch das Interface waren alle Bezeichner einheitlich, egal, welches Objekt dahinter stand.
Auch das Problem kann man sicher klassisch mit OOP lösen, aber ich fand die Lösung mit dem Interface schon ziemlich praktisch.

[Ghostwalker]

Hi,

da ich mich auch grad mit Interfaces beschäftige ist das natürlich auch für mich interresant.

Ein (wie ich meine) gute Beschreibung findest du im "Delphi Developer's Handbook" von Marco Cantú.


Die Vorteile die ich darin sehe, sind folgende:

- Übersichtlichkeit

Selbst wenn man nur alleine Entwickelt, sammeln sich im laufe der Zeit einiges an Klassen
an. Wenn ich die später nutzen möchte, interressiert mich nicht, wie ich das implementiert
hab, sonder welche Methoden/Propertys ich habe und Was gemacht wird.

- Sprachunabhängigkeit

Du kannst Klassen auch in anderen Sprachen (C,C++,C# oder what ever) schreiben und in Delphi
nutzen.

- COM/COM+/DCOM

Die Nutzung dieser Windows-Techniken ist schlicht und ergreifend ohne Interfaces nicht möglich,
da das ganze System drauf beruht (z.B. Einbindung von Word, Excel usw.). Auch die Nutzung
von ActiveX-Komponenten wird dadurch erst möglich.

Fazit (für mich soweit):

Es gibt etliche Situationen, in denen Interfaces sinnvoll einzusetzen sind. Deshalb aber zwanghaft
überall Inferfaces einzusetzen wäre aber übertrieben.

[DeddyH]

Noch ein Vorteil: man kann seine Klassen quasi in einer Art Baukastenprinzip designen. Eine Klasse soll etwas bestimmtes können: entsprechendes Interface implementieren. Sie soll auch etwas anderes können: weiteres entsprechendes Interface implementieren. Auf Verwenderseite kann man dann einfach abfragen, ob ein Interface implementiert ist und dies dann nutzen.

[bra]

Der einzige Grund, wieso ich bisher bewusst ein Interface eingesetzt habe (von COM und sowas mal abgesehen), war, dass ich Mehrfachvererbung für eine Klasse brauchte. Ist mir bis heute unverständlich, wieso Delphi sowas nicht unterstützt.

[einbeliebigername]

Hallo,

Zitat von bra:

Der einzige Grund, wieso ich bisher bewusst ein Interface eingesetzt habe (von COM und sowas mal abgesehen), war, dass ich Mehrfachvererbung für eine Klasse brauchte.

Was du meins ist, du brauchtest eine Mehrfachschnittstellenvererbung. Die ist ja auch relativ einfach umzusetzen.

Zitat von bra:

Ist mir bis heute unverständlich, wieso Delphi sowas nicht unterstützt.

Was du jetzt meins ist die Mehrfachverhaltensvererbung, welche leider nicht so trivial ist.

Zitat von Lemmy:

Ich finde, Interface-Programmierung verhält sich zu OOP wie die OOP zur prozeduralen Programmierung.

Jetzt fällt mir sofort "Objektorientierte Softwareentwicklung" aus Unizeiten ein. Was hat uns der OOS-Vorleser immer an den Kopf geworfen.

Zitat:

OOP ist nur syntaktischer Zucker.

Ja und da haben wir mit einer nicht OOP-fähigen Programmiersprache OOP-Programmiert und somit das Konzept hinter OOP kennen gelernt.

Eine Klasse besteht aus einer Schnittstelle und deren Implementierung. Eine Klasse kann die Schnittstelle zusammen mit deren Implementierung einer anderen Klasse erben. Und das Vererben der Implementierung ist OOP. Ein Interface ist somit quasi eine halbe Klasse, nämlich die Schnittstelle. Der Vorteil von OOP ist die Codereduzierung. Ohne OOP müsste man bei einem TNumberEdit größtenteils das komplette TEdit bis runter zu TObject nochmal neu implementieren. Mit OOP ist das nur eine klitzekleine Vererbung mit dem überschreiben einer virtuellen Methode. Interfaces bringen keine weitere Codereduzierung. Falsch eingesetzt erhöhen sie sogar die Menge an Code.

Und hiermit stelle ich an die Interface-Prediger mal eine Aufgabe. Baut doch mal TNumberEdit, TEdit bis runter zu TObject Interface-like nach ohne Klassenvererbung und ohne die Klassen aus VCL/RTL einzusetzen. Aber bitte mit Implementierung. Mich würde mal interessieren wie das denn aussehen würde.

Interface-Programmierung kann sich nicht zu OOP verhalten, weil sie teil dieser ist.

Zitat von Lemmy:

Grundsätzlich kannst Du jedes Problem auch ohne Interfaces und ohne OOP lösen.

Ja, aber auch ohne Hochsprache und Assembler.

Zitat von Lemmy:

Und keinen interessiert es.

Doch, denn das wie ist entscheidend. Die Vorteile der Hochsprachen haben dazu geführt das sie sich durchgesetzt haben. Bei OOP ist es das gleiche.

Zitat von Lemmy:

Genauso wenig wie

Delphi-Quellcode:

type
  TFoo = class(TObject)
  public
    procedure DoFoo; //mit 1.000 Zeile Code
  end;

objektorientierte Programmierung ist,

Wieso ist das kein OOP. Selbst ein schlichtes

Delphi-Quellcode:

programm Test;
uses
  System.SysUtils;
var
  X: TBytes;
begin
  X:= TEncoding.UTF8.GetBytes('Test');
end;

ist OOP, wegen dem TEncoding.UTF8.GetBytes .

Zitat von Lemmy:

ist die Definition eines Interfaces, die Implementierung und Verwendung davon automatisch auch eine sinnvolle Verwendung eines Interfaces, weil es oft schlicht und ergreifend nur mehr Arbeit ist aber keinen Vorteil bietet, weil man die Technik falsch anwendet bzw. im falschen Kontext.

Das habe ich jetzt auch nach mehrmals lesen nicht verstanden.

Zitat von Lemmy:

Interfaces sind eine logische Weiterführung der OOP, vielleicht müsste man auch sagen, eine zwingende Weiterführung.

Nein. Interfaces sind Teil von OOP.

Zitat von Lemmy:

Aber es ist wie gesagt nicht damit getan ein

Delphi-Quellcode:

type
  IFoo = Interface
    procedure DoFoo;
  end;

zu schreiben und zu Jubeln "Ich kann Interfaces", sondern dann folgen automatisch auch weiter Punkte die dann wichtig werden, denn Interfaces werfen wie vieles andere auch, mehr Fragen auf, als sie beantworten Als ein Stichpunkt werfe ich hier nur mal Dependency Injection ein.


Der große Vorteil von Interfaces eröffnet sich erst in etwas komplexeren Systemen, in denen div. Klassen miteinander kommunizieren müssen. Hier hast Du die Möglichkeit, dass diese Klassen weiterhin miteinander arbeiten könne, sich aber gegenseitig nicht mehr persönlich kennen müssen:

Das bekommst du aber auch ohne Interface hin. Ich sage nur reine abstrakte Klassen. Die haben mit Interfaces was gemeinsam. Denen fehlt auch die Implementierung der Schnittstelle.

Zitat von Lemmy:

Delphi-Quellcode:

TAdresse = class()
...
public
  function GetAnrede: String;
  function GetName1: String;
  function GetName2: String;
  function GetStrasse: String;
....
end;

TPerson = class()
private
  FName, FVOrname: String;
  FStrasse: String;
....
public
  property Adresse: TAdresse read FAdresse;

Und damit wir einen Konsumenten haben:

Delphi-Quellcode:

TBrief = class()
public
  procedure ErstelleBrief(Empfaenger: TAdresse);
end;

hier hast Du einen harte Kopplung wie sie in div. Projekten vorkommt und alles ist OK.
Willst Du jetzt aber TBrief durch einen Unittest jagen hast Du das Problem, dass Du zwingend auch eine Instanz von TAdresse erzeugen und übergeben musst. Kein Problem, solange TAdresse keine weiteren Abhängigkeiten hat. Sobald das System und das BOM komplexer werden, wirst Du hier immer mehr abhängige Klassen vorbereiten müssen, instanziieren müssen bis du zu dem Punkt kommst: Unittests sind scheiße, weil Du für eine Zeile Testcode, 10, 20 Zeilen Code für die Instanziierung und für die Aufräumaktionen brauchst. Und du merkst nicht, dass eigentlich dein Modell ein Problem hat.

Was hindert dich daran erst mal eine rein abstrakte klasse TBasisAdresse zu definieren. Dann kannst du im Unittest eine schicke TUnittestAdresse bauen. Und beim Erzeugen von Objekten helfen Klassenreferenzen, die richtige Klasse zu verwenden. Und sollte es auch noch nach Jahren richtig sein, das bei allen Kindern ein gewisser Teil der Implementierung gleich ist, kann dieser ruhig in der Basis-Klasse verweilen und braucht somit nur einmal Implementiert und einmal gewartet werden.

Zitat von Lemmy:

Mit Interfaces sieht das ganze so aus:

Delphi-Quellcode:

IAdresse = Interface
  function GetAnrede: String;
  function GetName1: String;
  function GetName2: String;
  function GetStrasse: String;
end;

TPerson = class()
private
  FName, FVOrname: String;
  FStrasse: String;
....
public
  property Adresse: IAdresse read FAdresse;

Und damit wir einen Konsumenten haben:

Delphi-Quellcode:

TBrief = class()
public
  procedure ErstelleBrief(Empfaenger: IAdresse);
end;

Nun kann TPerson selbst entscheiden, welche Implementierung von IAdresse (es kann mehrere geben) für seinen Zwecke am besten ist. TBrief ist das aber völlig egal, durch das Interface weiß die Klasse, dass die vertraglich vereinbarten Methoden vorhanden sind und funktionieren, d.h. Du kannst TBrief dann auch damit verwenden:

Delphi-Quellcode:

type
  TStudent = class(X,IAdresse)
  ...
  public
    function GetAnrede: String;
    function GetName1: String;
    function GetName2: String;
    function GetStrasse: String;

und TStudent muss kein weiteres Element deines TPerson-Frameworks kennen, muss nicht von einer gemeinsamen Basisklasse abgeleitet werden,....

Und du musst in jeder Klasse die Implementierung komplett neu hinschreiben, ob wohl sie bestimmt zu 90% identisch sind.

Zitat von Lemmy:

Kommen wir aber nochmal zurück zur TPerson: ich habe oben geschrieben, dass TPerson entscheidet welche Implementierung von IAdresse es verwendet. Das ist aber schon wieder ein Fehler! Weil du baust dir hier wieder über die Hintertür eine harte Kopplung von 2 Klassen ein. Und genau das kann später wieder zu einem Problem werden, weil du dann an dem Punkt bis: Verflixt, jetzt wollte ich harte Kopplung vermeinden, muss aber halt irgend wo implementieren:

Delphi-Quellcode:

TPerson = class()
private
  FName, FVOrname: String;
  FStrasse: String;
....
public
  property Adresse: IAdresse read FAdresse;

...

TPerson.Create()
begin
  FAdresse := TFooAdresse.Create();
end;

Lösung für dieses Problem bietet die Dependency Injection: Ich kopple das Interface nicht an einer bestimmten Stelle mit einer konkreten Implementierung sondern biete über eine Liste (sog. Container) verschiedene Möglichkeiten an (oder vielleicht auch nur eine) wie IAdresse implementiert sein soll. TPerson instanziiert dann die IAdresse nicht selbst, sondern fragt bei der Liste an: Gib mir eine Instanz von IAdresse. Aber den Part könnte Stefan G. nun wirklich besser erklären

Um diese Abhängigkeiten aufzulösen brauchst du aber nicht zwingend Interfaces. Das geht auch mit Klassenreferenzen.

Zitat von Lemmy:

wie auch bei der OOP ist auch bei Interfaces das Problem: Mit 2 Sätzen und einem einfachen Beispiel ist das nicht erklärt....

Ja, die Entscheidung Interfaces einzusetzen ist nicht einfach. Denn sie haben auch Nachteile.

Ich verwende auch Interfaces, aber sparsam. Bei mir ist das Verhältnis zwischen Interfaces und reiner Klassenvererbung gefühlt gleich dem in der VCL/RTL. Eigentlich benutze ich Interfaces nur da wo ich bei gemeinsamer Schnittstelle keine gemeinsame Vererbungslinie aufbauen kann. Für dieses Problem wünsche ich mir aber eine andere Lösung. Und jetzt mal ein Beispiel wie die andere Lösung aussehen müsste und wo Interfaces absolut nicht helfen.

Delphi-Quellcode:

Type
  TCustomLabeledControl<T: TControl>= class(T)
  strict private
    fLabel: TLabel;
  strict protected
    function GetLabelControlClass: TLabelClass; virtual;
  protected
    // Und viele override
  public
    constructor Create(AOwner: TComponent); override;
    procedure SetBounds(ALeft: Integer; ATop: Integer; AWidth: Integer; AHeight: Integer); override;
    // Und noch mehr override
  end;

  TLabeledEdit= class(TCustomLabeledControl<TEdit>);
  TLabeledComboBox= class(TCustomLabeledControl<TComboBox>);
  TLabeledMemo= class(TCustomLabeledControl<TMemo>);
  TLabeledRichEdit= class(TCustomLabeledControl<TRichEdit>);

implementation

constructor TCustomLabeledControl<T: TControl>.Create(AOwner: TComponent);
begin
  inherited;
  fLabel:= GetLabelControlClass.Create(nil); // Oder auch Self wie man mag
end;
 
function TCustomLabeledControl<T: TControl>.GetLabelControlClass: TLabelClass;
begin
  Result:= TLabeledControlManager.Instance.GetLabelControlClass(…); // Einen String, Enum, Self oder was auch immer passent ist übergeben
end;

procedure TCustomLabeledControl<T: TControl>.SetBounds(ALeft: Integer; ATop: Integer; AWidth: Integer; AHeight: Integer);
begin
  inherited;
  fLabel.SetBounds(…);
end;

einbeliebigername.

[Jim Carrey]

Wenn ich das bisher richtig verstehe geht es bei Interfaces quasi vordergrundig um die Komprimierung des Codes.

[frapo]

Zitat von Jim Carrey:

Wenn ich das bisher richtig verstehe geht es bei Interfaces quasi vordergrundig um die Komprimierung des Codes.

Eigentlich überhaupt nicht.

Interfaces und somit OOP stehen für ein Paradigma, dass Wartbarkeit und Erweiterbarkeit, sowie Architektur von Software im Fokus hat.

Siehe z.b.:
http://openbook.rheinwerk-verlag.de/oop/

Das ist kein Thema, dass man mal eben in 30 Minuten vollständig erfassen kann.

Mir kommt es in diesem Thread eh so vor, als ob man beim Begriff Interface(im Sinne von OOP), nicht von der selben Definition ausgeht.
Der eine spricht von DLL's oder einer anderen Schnittstellentechnik, der andere missbraucht Interfaces für die sogenannte Mehrfachvererbung.
Siehe dazu vielleicht: https://de.wikipedia.org/wiki/Schnit...schnittstellen

Vielleicht liegt das an der Geschichte von Pascal/Object-Pascal(als ehemals imperative Programmiersprache) und die stete Bindung an die DLL-Hell. Java sowie C# machen ja eigentlich sehr schnell verständlich, was und wofür Interfaces eingesetzt werden.

C++, ich glaube auch Perl und Phyton, sind momentan die einzigen populären Sprachen, die auf Mehrfachvererbung setzen. Es gibt Gründe dafür und auch gute Gründen dagegen. Das muss dann jeder für sich ausmachen. Ich bin da persönlich sehr zufrieden, dass Mehrfachvererbung in Java, C# und Delphi nicht möglich ist. Die Architektur einer Software ist schon kompliziert genug.

[Lemmy]

Zitat von einbeliebigername:

Der Vorteil von OOP ist die Codereduzierung. Ohne OOP müsste man bei einem TNumberEdit größtenteils das komplette TEdit bis runter zu TObject nochmal neu implementieren. Mit OOP ist das nur eine klitzekleine Vererbung mit dem überschreiben einer virtuellen Methode. Interfaces bringen keine weitere Codereduzierung. Falsch eingesetzt erhöhen sie sogar die Menge an Code.
...
Und hiermit stelle ich an die Interface-Prediger mal eine Aufgabe. Baut doch mal TNumberEdit, TEdit bis runter zu TObject Interface-like nach ohne Klassenvererbung und ohne die Klassen aus VCL/RTL einzusetzen. Aber bitte mit Implementierung. Mich würde mal interessieren wie das denn aussehen würde.

ich bin mir sicher hier aufmerksam mit gelesen zu haben. Du bist der erste der diese Behauptung aufstellt. Wie kommst Du auf diesen Zweig? Niemand hat die Sinnhaftigkeit von Vererbung angezweifelt.

Zitat von einbeliebigername:

Zitat von Lemmy:

Genauso wenig wie

Delphi-Quellcode:

type
  TFoo = class(TObject)
  public
    procedure DoFoo; //mit 1.000 Zeile Code
  end;

objektorientierte Programmierung ist,

Wieso ist das kein OOP.

eine monolithische Prozedur in eine Klasse packen in dem ich TFoo = Class drum herum schreibe ist keine OOP. Das ist lediglich Mehraufwand.

Zitat von einbeliebigername:

Selbst ein schlichtes

Delphi-Quellcode:

programm Test;
uses
  System.SysUtils;
var
  X: TBytes;
begin
  X:= TEncoding.UTF8.GetBytes('Test');
end;

ist OOP, wegen dem TEncoding.UTF8.GetBytes .

ein Methodenaufruf ist für dich OOP? Im Ernst? das ist Anwendung einer Klasse. mehr nicht.

Zitat von einbeliebigername:

Zitat von Lemmy:

Interfaces sind eine logische Weiterführung der OOP, vielleicht müsste man auch sagen, eine zwingende Weiterführung.

Nein. Interfaces sind Teil von OOP.

wäre das ein C++ Forum würde ich dir recht geben und hätte das auch nicht geschrieben. Dort bestand von Anfang an die Trennung zwischen Interface (Header) und Implementierung, das gab es in Delphi erst als es auch Interfaces gab. OOP geht in Delphi wunderbar ohne Interfaces weil alles in einer Datei implementiert wird (werden muss) die Möglichkeit das zu trennen bieten erst Interfaces. Und die waren in C++ von Anfang an so eingeplant. Daher bleibe ich dabei: Die sind die logische Fortsetzung.

Zitat von einbeliebigername:

Das bekommst du aber auch ohne Interface hin. Ich sage nur reine abstrakte Klassen. Die haben mit Interfaces was gemeinsam. Denen fehlt auch die Implementierung der Schnittstelle.

sicher bekomme ich das auch mit einer abstrakten Basisklasse hin. Was ist aber, wenn ich keine gemeinsame abstrakte Basisklasse definieren will / kann? Wenn ich keine Interfaces hätte müsste ich zwangsläufig irgend wo aus dem Framework eine gemeinsame Elternklasse raus suchen und von der einen Erben erstellen - selbst dann wenn ich das nicht will, weil ich damit Abhängigkeiten eingehe. Mit Interfaces muss ich das nicht.

Habe ich dagegen ein Interface zur Verfügung muss ich lediglich das implementieren und ich kann eine externe Funktionalität nutzen. Schau dir nochmal mein Beispiel an: TStudent muss von "Framework" um TBrief und TPErson nichts kennen, es musss lediglich IAdresse implementieren und schon kann ich die beiden Frameworks gemeinsam nutzen.

[Mikkey]

Zitat von Lemmy:

wäre das ein C++ Forum würde ich dir recht geben und hätte das auch nicht geschrieben. Dort bestand von Anfang an die Trennung zwischen Interface (Header) und Implementierung, das gab es in Delphi erst als es auch Interfaces gab. OOP geht in Delphi wunderbar ohne Interfaces weil alles in einer Datei implementiert wird (werden muss) die Möglichkeit das zu trennen bieten erst Interfaces. Und die waren in C++ von Anfang an so eingeplant. Daher bleibe ich dabei: Die sind die logische Fortsetzung.

Tut mir leid, wenn ich da reinrede, aber C++ hat (jedenfalls im Standard) keine Interfaces. Die sind bei C++ auch nicht erforderlich, weil es schließlich Mehrfachvererbung gibt. Tatsächlich benutzt man letztere um Interfaces abzubilden.
Die vom COM bekannten Interfaces kann man sogar mit normalem C implementieren und nutzen.