Schon wieder: Warum Interfaces

[Mavarik]

Was mir noch einfällt.

Beispiel mit : IStreamPersist

Delphi-Quellcode:

TFoo = Class(TInterfacedObject,ICanCompress);
...
TBar = Class(TInterfacedObject,ICanCompress,IStreamPersist)

Jetzt kann ich abfragen, ob ein Object, dass Interface unterstützt. Und dann in einen Stream schreiben oder vom Stream lesen...

[Jim Carrey]

Kompliziert kompliziert

Ich finde dann doch den ausführlichen alten Code besser.

[stahli]

@Aviator

Das ist gut zusammengefasst.

Interfaces sind halt nur in bestimmten Konstellationen sinnvoll.
Wenn Du ein paar Klasen in einem übersichtlichen Projekt nutzt, ist der Mehraufwand von Interfaces meist nicht zu rechtfertigen.

Wenn Du aber sehr viele Klassen in einem komplexen System nutzt und möglicherweise mehrere Klassen gleiche Funktionalitäten unterstützen müssen, dann helfen Interfaces sehr stark.

Auch die Übersichtlichkeit über die Projektbestandteile wird verbessert wenn man alle genutzten Interfaces in einer Unit vor sich hat und deren Beziehungen direkter nachvollziehen kann als wenn man konkrete Klassen in unterschiedlichen Units nachschlagen muss.

Auch sehr hilfreich finde ich, dass die Units, die die Klassen deklarieren, nur an einer zentralen Stelle bekannt sein müssen.
Die Unit1 muss nicht Unit2 kennen und umgekehrt. Beide - und auch die anderen Projektbestandteile - müssen nur MyInterfaces und MyFactory kennen und haben damit Zugang zu allem Benötigten.


@Jim

So kompliziert ist das gar nicht - ich hab´s ja auch verstanden.

Das ist wie vor ein paar Jahren, als alle sich fragten, was das mit den Objekten eigentlich soll...

Irgendwann findet man schon etwas, wo dann Interfaces plötzlich sinnvoll erscheinen.

[Jim Carrey]

Zitat:

So kompliziert ist das gar nicht - ich hab´s ja auch verstanden.

Das klingt total bawertend

Zitat:

Irgendwann findet man schon etwas, wo dann Interfaces plötzlich sinnvoll erscheinen.

Dafür muss man sie aber erst verstehen

[DeddyH]

Ich hab mich auch 20 Jahre davor gedrückt, als ich mich aber vor Kurzem damit beschäftigt habe, war das eigentlich simpel zu verstehen.

[Aviator]

Zitat von Jim Carrey:

Zitat:

So kompliziert ist das gar nicht - ich hab´s ja auch verstanden.

Das klingt total bawertend

Er hat es ja auf sich selbst bezogen. Wenn er es versteht, dann verstehen es auch alle anderen.
Immerhin hat er Humor.

Zitat von stahli:

@Aviator

Das ist gut zusammengefasst.

Danke!

Interfaces sind wie schon beschrieben sowohl positiv als auch negativ. Das Prinzip wie sie funktionieren habe ich mittlerweile doch recht gut verstanden. Und das ist immer das Wichtigste (bei allem im Leben). Man muss das Prinzip verstehen.

Nur manchmal sehe ich eben keine Notwendigkeit dafür oder weiß nicht, das an einer bestimmten Stelle ein Interface von Vorteil wäre. Da tue ich mich aktuell noch ein bisschen schwer damit.


Zur Delphi IDE kann ich sagen, dass mich lediglich das Verfolgen einer durch ein Interface implementierten Methode etwas stört. STRG + Linksklick auf den Aufruf einer Interface-Methode führt immer nur zum Interface selbst. Wenn man sich mal Visual Studio anschaut, dann führt es einen immer direkt zu der Klasse, welche oben auch instanziiert wurde. (Ich hoffe ich verwechsele das nicht)

Das würde ich mir bei Delphi auch wünschen. Aber ich will jetzt keine Diskussion starten, welche IDE in dem Fall besser wäre. Ist nur meine persönliche Meinung.

[stahli]

Die Darstellung der Interfaces in den überwachten Ausdrücken kann man sich etwas optimieren: http://www.delphipraxis.net/189852-u...ptimieren.html

Es ist leider etwas aufwendig, aber zumindest geht es.

[Aviator]

Zitat von stahli:

Die Darstellung der Interfaces in den überwachten Ausdrücken kann man sich etwas optimieren: http://www.delphipraxis.net/189852-u...ptimieren.html

Es ist leider etwas aufwendig, aber zumindest geht es.

Ja das Thema hatte ich damals mitverfolgt. Nur habe ich mich damit nicht mehr weiter auseinander gesetzt. Muss man dann für jedes Interface einen eigenen Visualizer bauen? Das wäre ja extrem aufwendig.

[stahli]

Zitat von Aviator:

Zitat von stahli:

Die Darstellung der Interfaces in den überwachten Ausdrücken kann man sich etwas optimieren: http://www.delphipraxis.net/189852-u...ptimieren.html

Es ist leider etwas aufwendig, aber zumindest geht es.

Ja das Thema hatte ich damals mitverfolgt. Nur habe ich mich damit nicht mehr weiter auseinander gesetzt. Muss man dann für jedes Interface einen eigenen Visualizer bauen? Das wäre ja extrem aufwendig.

Ja, wobei Vererbungen bei der Darstellung berücksichtigt werden können.
Wenn man also eine Darstellung für IMyInt hat, kann diese auch für IMyIntA und IMyIntB genutzt werden.
Wobei man Ableitungen von Interfaces eher vermeiden sollte. Hier werden ja eher Funktionalitäten beschrieben und dabei ist es i.d.R. sinnvoll, viele kleine eigenständige Funktionalitäten (Interfaces) zu definieren als von anderen abzuleiten.

Wenn man IMyInt1 und IMyInt2 und möchte jetzt ein IMyInt3, das die beiden anderen implementiert, könnte man ja nur von einem ableiten und müsste den anderen Bereich wieder nachbilden.

Besser wäre es somit, in IMyInt3 nur die Neuerungen zu definieren und einer späteren Klasse alle drei Interfaces zuzuweisen:

TMyClass = class(TInterfacedObject, IMyInt1, IMyInt2, IMyInt3)

Also, da Vererbungen von Interfaces die Ausnahme sein werden, wäre für jedes Interface eine eigene Visualisierung zu regeln.
Das kann man aber in Form von Bedingungsprüfungen in einer Unit regeln:
if (TypeName = 'IMyInt1') then
...
if (TypeName = 'IMyInt2') then
...

Zitat von DeddyH:

Eine goldene Regel dafür kenne ich auch nicht, aber je dynamischer (besonders im Hinblick auf die Klassentruktur) und/oder offener (im Hinblick auf externe Schnittstellen) ein Projekt wird, desto sinnvoller wird der Gebrauch von Interfaces IMO.

Wenn man irgendwann zu einem Punkt kommt, dass man der einen Klasse ja noch die und die Klasse und der nächsten Klasse die und die bekanntgeben muss und vielleicht wegen Kreuzbezügen das gar nicht mehr hin bekommt, dann ist ein guter Zeitpunkt für Interfaces.

Wenn man schon bei der Planung eines Projektes zu dem Schluss kommt, dort irgendwann mal zu landen, dann sollte man gleich mit Interfaces starten.
So spart man sich den Aufwand der späteren Umstellung, da das doch auf einiges Auswirkungen hat.


Ich habe gerade ein nicht sehr umfangreiches Projekt der Einfachheit halber mit Klassen begonnen und habe mich jetzt doch entschieden, das nochmal umzustellen.
Das ist zwar etwas mehr Schreibarbeit aber der Ablauf und die Beziehungen der einzelnen Projektteile ist dadurch deutlich übersichtlicher.

[Jumpy]

Ich meine einer hat es schon erwähnt, aber beim 2. durchlesen des Threads hab ich es nicht mehr gefunden:
Gerade wenn man viel mit Unittests usw. arbeitet macht die Verwendung von Interfaces die Klassen leichter testbar, da so eine entkopplung von konkreten Implementierungen stattfindet. Und da Entkopplung eines der hohen Ziele der OOP bzw. auch des CleanCodes ist, wird das halt vielfach so gepredigt. Wie schon Lemmy sagte. Es reicht nicht nur Interfaces zu verwenden und alles ist gut. Man muss sie auch richtig verwenden, im richtigen Zusammenhang.