Dies ist die zweite Staffel eines Themas von 2016, das - wie üblich - zum Schluss völlig wegmäanderte.

Wie der TE damals weiß auch ich so halbwegs, was Interfaces sind, wie man sie konstruiert und wozu sie gut sein sollen. Ich weiß auch, dass die Beispiele, wozu Interfaces nützlich sind, aus Demonstrationsgründen meist so einfach gestrickt sind, dass man auch gut ohne sie klarkäme. Wie der TE höre ich immer feurige Beteuerungen, dass es ohne Interfaces nicht geht (vor allem, wenn man auf Nick Hodges hört), und wie er tue ich mich schwer, für mein eigenes Programm eine Stelle zu finden, wo Interfaces eine Verbesserung wären.

Ich stelle gerade von AsyncCalls von Andreas Hausladen auf Omnithread von Primož Gabrijelčič um. Beide benutzen natürlich heftigst Interfaces. Und insbesondere anhand des sehr überschaubaren Quelltextes von AsyncCalls fände ich eine Darlegung lehrreich, warum Interfaces und ob es auch ohne sie ginge. Denn hier greift doch das häufige Argument "Die spätere Implementierung ist zurzeit noch nicht bekannt und man hält sich alles offen" nicht. Und Gabrijelčič schreibt an irgendeiner Stelle (die ich gerade nicht mehr finde) sinngemäß: Man kann das Interface nehmen oder auch die Klasse, wenn man das bevorzugt. Na, wenn das so ist, denkt man sich, warum nicht gleich nur Klassen?

JETZT geht es oft auch ohne sie, nachdem endlich, nach Jahrzehnten des Wartens, die Records erweitert wurden.

Im Grunde werden hier Interfaces "oft" nur dafür genutzt, damit Objekte automatisch freigegeben werden.
In den NextGen-Compilern ala Android und iOS, gab es mit dem ARC auch dafür schon blöde eine Lösung, da ALLE Delphi-Objekte wie Interfaces behandelt wurden,
und auch jetzt kann man mit den neuen Managed Records sowas überall im Delphi nutzen, also nun auch im Windows.


Persönlich hab ich oft versucht ohne Interfaces auszukommen, vor allem um die doppelte Deklaration und zusätzliche Zwischenebene loszuwerden.

Zitat von himitsu:

Persönlich hab ich oft versucht ohne Interfaces auszukommen, vor allem um die doppelte Deklaration und zusätzliche Zwischenebene loszuwerden.

Das ist es ja gerade, alles in den Interfaces muss ja in jedem Fall implementiert werden, also was bringt (hier) die Doppelarbeit?
Ja, die Referenzzählung. Aber das mache ich lieber selbst und das stört mich nicht. Bei der Referenzzählung gibt es auch Fallen, und dann kann man das gleich selbst erledigen.

Was das mit Managed Records zu tun hat, habe ich nicht verstanden. Warum nicht Klasse und gut ist?

Auch wenn viele Delphi-Entwickler das zu glauben scheinen ist der primäre Zweck von Interfaces nicht die Referenzzählung, sondern die Abstraktion. Einer Klasse oder Routine, die ein bestimmtes Interface erwartet, sind die konkrete Implementation und der konkrete Typ völlig egal. Das bedeutet, dass für die Nutzung auch keine bestimmte Klassenhierarchie eingehalten werden muss, es kann jede beliebige Objektinstanz übergeben werden, sie muss lediglich das Interface implementieren.

Die nicht notwendige Freigabe ist ein (ggf.) positiver Effekt von Interfaces.
Der Nachteil ist die doppelte Deklaration (den möchte ich mit meinem UnitOptimizer abstellen, so dass das automatisiert gemacht wird).

Managed Records müssen nicht freigegeben werden. Wenn es nur um das Unterlassen der Freigabe geht, kann man jetzt diese benutzen.
Dann hat man allerdings nicht so etwas wie Vererbung.

Ein zweiter Wesentlicher Vorteil von Interfaces ist die Zuweisung von mehreren Interfaces zu einer Klasse.
Man kann also "Fähigkeiten" definieren, die von unterschiedlichen Klassen erfüllt werden können.
Alles, was "CanFly" unterstützt, kann man dann fliegen lassen. Egal ob Vogel, Biene oder Flugzeug.

Diese Option hat man eben nur mit Interfaces.

Ein Nachteil ist, dass sie deutlich langsamer sind und mehr Speicher brauchen als reine Objekte und Records.

Zitat von Benmik:

Dies ist die zweite Staffel eines Themas von 2016, das - wie üblich - zum Schluss völlig wegmäanderte.

Und inwiefern hat das nicht die Frage beantwortet?

Ich bin mal böse: Umgekehrt, braucht keine interfaces wenn man Delphi nur dazu benutzt um Programme zusammenzubasteln.

@DeddyH: Ja, der primäre Zweck vom Erfinder, aber nicht der primäre Zweck warum es oft eingesetzt wird, denn da ist es oft nur die Referenzzählung,
und da kann man auch gut ohne auskommen.

Also wenn das Interface nur innerhalb einer Komponente steckt, nur der Referenzzählung dient und wo der Unterbau auch nicht austauschbar ist.

Zitat:

Diese Option hat man eben nur mit Interfaces.

Oder mit Objekten, wo der Vorfahre fliegen kann und durch überschreiben (override) verschiedene Ableitungen das dann anpasssen.
TStrings/TDataSet/TCollection/...

Interface: erst wird der Vogel erfunden und anschließend das Fliegen als Gemeinsamkeit zwischen den verschiedenen Tieren/Maschienen dann geteilt
Vererbung: erst erfindet man das Fliegen und baut daraus dann z.B. einen Vogel oder ein Flugzeug

Nur bei Mehrfachvererbung und bei nachträglichen Erweiterungen hapert es dann etwas: TLebewesen -> TLaufen -> TFliegen -> TVogel oder TFlugzeug

und um nochmal auf das Thema zu kommen:

Zitat von freimatz:

Zitat von Benmik:

Dies ist die zweite Staffel eines Themas von 2016, das - wie üblich - zum Schluss völlig wegmäanderte.

Und inwiefern hat das nicht die Frage beantwortet?

Zitat von freimatz:

Ich bin mal böse: Umgekehrt, man braucht keine Interfaces, wenn man Delphi nur dazu benutzt, um Programme zusammenzubasteln.

Das ist es ja, wie alle anderen möchte ich natürlich lieb sein und kein böser Pfuscher, der Programme nur zusammenbastelt.

Bitte nochmal die Intention beachten, derentwegen ich den alten Thread auch nicht ausgegraben und reanimiert, sondern einen neuen eröffnet habe: Meine Bitte war, anhand von anspruchsvollem, realem Code konkret den Nutzen der dort verwendeten Interfaces aufzuzeigen und mir (und anderen) verständlich zu machen.

Um Missverständnisse zu vermeiden: Es ist nicht meine Intention, gegen Interfaces zu stänkern. Ich glaube nicht, dass man sie eingeführt und sich viel Arbeit damit gemacht hätte, wenn sie nicht nützlich wären. Wie viele andere schaffe ich nur nicht den Sprung, für mich eine konkrete Anwendung für sie zu finden. Kann gut sein, mein Code ist dafür nicht anspruchsvoll genug, wäre völlig OK. Ich sehe aber auch bei AsyncCalls den Nutzen nicht, und hier wäre ein kompetenter Fingerzeig einfach sehr willkommen.

Nur ein Anwendungsfall von vielen: Class Factory