Schon wieder: Warum Interfaces

[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.

[Lemmy]

Zitat von 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.

Ich gebe zu, dass ich kein C++ Profi bin, aber in C++ gibt es Headerdateien und es wird empfohlen Header und Implementierung zu trennen. Oder bin ich da auf dem Holzweg?

[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.

[Mikkey]

Headerdateien sind keine Interfaces. Nur, weil in Delphi der Anfang der Quelldatei sich "Interface" nennt, ist der dazu in C++ analoge Teil (die Headerdatei) noch lange keins.

Headerdateien sind dazu da, Vorwärtsdeklarationen und Extern-Deklarationen für die Verwendung der in der C++-Datei enthaltenen Implementierung bereitzustellen.

Interfaces (und bei C++ abstrakte Basisklassen) werden verwendet,
- um verschiedene Implementierungen von gleichartigem Code verwenden zu können
- um Fassaden- und Adapter-Patterns zu realisieren
- um Unit-Tests viel (!) einfacher zu machen, selbst wenn die getesteten Klassen im System "mittendrin" verwendet wird.

In Delphi wird unglücklicherweise die Interface-Verwendung mit der Referenzzählung und automatischer Freigabe gekoppelt. Deshalb wird das auch häufig missverstanden.

[MyRealName]

Ich weiss nicht, ob es genannt wurde, woltle jetzt keine 6 Seiten lesen :

Mit einem interface kann ich 2 komplett verschiedene Klassen miteinander verbinden, zum Bsp. TTreeView und TListView, da könnte man dann ein AddItem in einem interface hinzufügen und dann ohne die klasse zu kennen über das interface AddItem aufrufen.

[DeddyH]

Nach meinem Verständnis ist genau das der Sinn von Interfaces: Abstraktion. Angenommen, wir haben eine Klassenstruktur mit 2 Zweigen: TFoo und TBar. Wollen wir jetzt einer Methode eine Instanz als Parameter übergeben, welche wiederum eine Methode der übergebenen Instanz aufruft, und diese Instanz soll entweder TFoo oder TBar (oder eine Ableitung einer der beiden) sein, dann haben wir 3 Möglichkeiten:
1. Deklaration einer Basisklasse mit dieser Methode, von der sowohl TFoo als auch TBar abgeleitet werden, der Parameter ist dann vom Typ der Basisklasse
2. Eine Abfrage innerhalb der aufrufenden Methode, ob die Parameter-Instanz TFoo oder TBar ist, der Parameter ist dann vom Typ TObject
3. Definition eines Interfaces, das von irgendeiner (oder auch mehreren) Klasse innerhalb der Struktur implementiert wird und Deklaration des Parameters als Typ dieses Interfaces

2 ist die unsauberste und unflexibelste Lösung, da sind wir uns wohl einig. 1 ist ein gangbarer Weg, kann aber bei mehreren solcher Fälle schnell unübersichtlich werden und dazu führen, dass schon die Basisklasse mit Methoden überfrachtet wird, die erst weiter unten im Zweig tatsächlich benötigt werden. Und zu 3: wie war nochmal der Titel dieses Threads?

[einbeliebigername]

Hallo,

Zitat von Jim Carrey:

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

Nein, komprimieren tut man den Code durch Vererbung. Interfaces falsch angewendet blähen den Code nur auf. Selbst Richtig kann dazu führen das man mehr Code hat.

Zitat von 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.

Da habe ich mehrere Aussagen, auch aus anderen Quellen, welche ich nicht mehr zusammen bekomme, zu dem Thema in ein Topf geworfen. Vieleicht falsch umgerührt und wieder mal etwas überspitzt. Was ich aber als Reaktion auf meine Aufgabe erwartet habe, war ein schlichtes geht nicht, weil es nicht zu schaffen ist, weil keiner so viel Zeit hat! In den Klassen steckt schon viel Code drin der durch Vererbung wiederverwendet wird.

Zusammenfassung von Daten und Methoden in Verbindung mit Vererbung ist OOP. Vererbung ist das was dabei die Wiederverwendbarkeit von Sourcecode verbessert. Die Zusammenfassung von Daten und Methoden verbessert die Verständlichkeit. Damit man so viel wie möglich Code wiederverwendet setzt man Vererbung ein wo es nur geht. Interfaces bleiben dann nur für die Spezialfälle, wo Vererbung nicht mehr funktioniert. Bei einer Schnittstelle zwischen DLL und Anwendung kommt man mit Vererbung nicht zum Ziel, da braucht man und sollte man Interfaces einsetzen. Aber bei so simplen wie TAdresse gleich mit Interface anzufangen bläht den Code nur unnötig auf.

Zitat von Lemmy:

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.

Die Klasse TFoo erbt zumindest was von TObject, wenn auch nicht viel. Wenn man in dem Beispiel die Elternklasse durch TForm austauscht, sieht man das deutlicher. Eine Klasse, die 99,9% des Codes von der Elternklasse erbt und durch eine einzige Zeile ein verändertes Verhalten erzeugt, ist OOP.

Zitat von Lemmy:

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.

Eine Klasse kannst du gar nicht ohne OOP anwenden, weil sie schlicht nicht existieren könnte. Und wenn man bei dem Beispiel mal genau hinter die Funktionsweise der mindesten zwei Klassen schaut, stellt man fest das dort schon sehr viel OOP (virtual; abstract; ) bemüht wird.

Zitat von Lemmy:

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.

In C++ kann man, soweit ich noch weiß, die Implementierung auch in die Header-Datei schreiben. Der Compiler verarbeitet das auch brav. Das erzeugt zwar hier und da Probleme und ist kein gutes C++. Aber man kann damit was funktionsfähig bauen. Man kann aber auch die Klasse komplett in die CPP schreiben, wie in Delphi implementation-Teil. Auch wenn man in anderen Sprachen es nicht so leicht sieht wie in Delphi, haben Klassen automatisch eine Schnittstelle (im eng. ein Interface). Und noch mal, Interfaces sind Teil von OOP. Die logische Fortsetzung von OOP sind Generics.

Zitat von Lemmy:

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 du nicht willst, machst du in meinen Augen was falsch. Wenn es aber nicht geht, weil es aus Gründen schon verschiedene Elternklassen gibt, oder es unterschiedliche Kombinationen von Schnittstellen geben kann, dann sind aktuell Interfaces die Wahl.

Zitat von Lemmy:

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.

Ja ich kenne viele Beispiele. Keines geht wirklich auf den Fakt ein, dass oft größere Teile bei den Interface-Implementierungen Copy and Past sind und erklärt wie man das vermeidet. Ich setze doch selbst Interfaces ein. Nur das bei mir Interfaces die letzte Wahl sind und ich nicht mal ansatzweise Begriffe wie Interface-Programmierung oder IOP einführen würde. Ich selbst zu zwingen mich erst mal über eine Vererbungsmöglichkeit nachzudenken, denn man kann es nicht oft genug sagen, Vererbung ist das was Code reduziert.

Und schaue dir doch mal bitte mein Gegenbeispiel mit den LabeledControls an und sag mir wie die Zauberinterfaces (Auch diesen Begriff habe ich aus vielen Aussagen überspitzt zusammengesetzt) das Problem lösen. Interfaces können nicht zauber. Sie sind auch nicht die einzige Möglichkeit Abhängigkeiten aufzulösen. Sie sind sogar in gewisser Weise gefährlich.

Zitat von MyRealName:

Ich weiss nicht, ob es genannt wurde, woltle jetzt keine 6 Seiten lesen :

Mit einem interface kann ich 2 komplett verschiedene Klassen miteinander verbinden, zum Bsp. TTreeView und TListView, da könnte man dann ein AddItem in einem interface hinzufügen und dann ohne die klasse zu kennen über das interface AddItem aufrufen.

Es wurde denke ich schon angesprochen, vielleicht nicht so deutlich. Ja und das ist genau der Fall, wo man aktuell nur mit Interfaces weiter kommt. Ich wünsche mir, dass man das auch mit Vererbung lösen könnte.

Zitat von DeddyH:

2 ist die unsauberste und unflexibelste Lösung, da sind wir uns wohl einig. 1 ist ein gangbarer Weg, kann aber bei mehreren solcher Fälle schnell unübersichtlich werden und dazu führen, dass schon die Basisklasse mit Methoden überfrachtet wird, die erst weiter unten im Zweig tatsächlich benötigt werden. Und zu 3: wie war nochmal der Titel dieses Threads?

Ja genau: Erst über 1. gründlich nachdenken, dann es mit 3. versuchen und wenn alle Stricke reißen, 2. verwenden. Bei 2. sollte man sehr sehr selten ankommen. Und das Verhältnis von 1. und 3. sollte deutlich zu 1. tendieren.

Was ich noch für Interfases gelten lassen würde, währ das Argument, dass man durch Interfases die Schnittstelle für eine Funktionalität deutlicher abgrenzen kann. Das müsste man aber ohne Zusätzliche Implementierung schaffen können. Also ein einfaches sinnfreies Beispiel. Man hat mehrere Formularklassen. Bei jeder will man die Caption von außen verändern können. Der Teil der Schnittstelle in der Basisklasse von den Formularklassen ist das Property Caption. Den Rest braucht man nicht für diese Aufgabe. Also könnte man jetzt mittels eines Interface den Teil abgrenzen, wie folgt:

Delphi-Quellcode:

iFormCaption= interface
  property Caption: string;
end;
TMyForm= class(TForm, iFormCaption)
end;

Die Implementierung des Interface führt nicht zu mehr Code, da das was im Interface verlangt wird bereit in der Basisklasse vorhanden ist. Leider macht Delphi da einem wieder mitunter einen dicken Strich durch die Rechnung. Bei Properties in Interfaces muss man Getter (wenn man lesen will) und Setter (wenn man schreiben will) angeben. Das führt im konkreten Beispiel dazu, dass man in jeder Formularklasse, welche iFormCaption implementiert auch den Getter und Setter implementieren muss. Die sehen aber immer identisch aus. Selbst wenn man es schafft Getter und Setter in einer Basisklasse zu implementieren, ist das noch ein unnötiges aufblähen des Codes.

einbeliebigername.

[DeddyH]

Zitat von einbeliebigername:

Und das Verhältnis von 1. und 3. sollte deutlich zu 1. tendieren.

Das würde ich so pauschal nicht stehen lassen, es kommt immer auf den Einzelfall an. Will ich z.B. eine Art Framework schreiben, dann sollte ich mir sehr genau überlegen, ob ich nicht lieber von Anfang an auf Interfaces setze, da wahrscheinlich die unterschiedlichsten Typen auf mich zukommen. Da wird es dann sehr schwer bis schlicht unmöglich, eine saubere Klassenstruktur hinzubekommen. Das Schöne an der Verwendung von Interfaces ist es ja gerade, dass mich der dahinterliegende Typ nicht im Geringsten interessiert und ich mich somit auf die Methoden und Eigenschaften konzentrieren kann, die im Interface zugesichert wurden.

[einbeliebigername]

Hallo,

Zitat von DeddyH:

Zitat von einbeliebigername:

Und das Verhältnis von 1. und 3. sollte deutlich zu 1. tendieren.

Das würde ich so pauschal nicht stehen lassen, es kommt immer auf den Einzelfall an. Will ich z.B. eine Art Framework schreiben, dann sollte ich mir sehr genau überlegen, ob ich nicht lieber von Anfang an auf Interfaces setze, da wahrscheinlich die unterschiedlichsten Typen auf mich zukommen. Da wird es dann sehr schwer bis schlicht unmöglich, eine saubere Klassenstruktur hinzubekommen. Das Schöne an der Verwendung von Interfaces ist es ja gerade, dass mich der dahinterliegende Typ nicht im Geringsten interessiert und ich mich somit auf die Methoden und Eigenschaften konzentrieren kann, die im Interface zugesichert wurden.

Aber wie schaffst du es, ohne über Klassenstrukturen nachzudenken, bei der Implementierung eines Interfaces in mehreren Klassen Codeduplikate zu vermeiden. Um bei dem iAdresse-Beispiel zu bleiben. Wenn man TAdresse1= class(iAdresse) , TAdresse2= class(iAdresse) und TAdresse3= class(iAdresse) hat, dann haben doch die drei Klassen jeweils ein function GetFirstName: string; . Der Funktionsrumpf sieht doch bei allen gleich aus ( begin result:= fFirstName; end; ). Also kommt man doch zum Schluss GetFirstName in eine Basisklasse zu verschieben. Bestimmt sind 90-100% der Implementierung von iAdresse gleich. Dann kann man doch auch das Interface in der Basisklasse implementieren. Und damit wäre die Basisklasse die einzige, welche das Interface implementiert. Und somit wäre das Interface überflüssig. Sei denn du willst, das jemand auch TFormAdresse= class(TForm, iAdresse) machen kann, was ich softwaredesigntechnisch für eine absolute Katastrophe halte.

Schon allein der Umstand, dass ein Property im Interface einen Getter in der implementierenden Klasse benötigt, reicht für mich aus, Interfaces ausschließlich nur da einzusetzen, wo es mit Vererbung und abstrakten Klassen keine Lösung gibt.

einbeliebigername.