Schon wieder: Warum Interfaces II

[himitsu]

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.

[Benmik]

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?

[DeddyH]

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.

[himitsu]

@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

[stahli]

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.