Schon wieder: Warum Interfaces II

[sakura]

Zitat:

Zitat von Benmik (Beitrag 1468022)

Meine Bitte war, anhand von anspruchsvollem, realem Code konkret den Nutzen der dort verwendeten Interfaces aufzuzeigen und mir (und anderen) verständlich zu machen.

Das wird eher nicht passieren, da dieser Code meist "anspruchsvoll" ist. Dafür wird sich kaum einer die Zeit nehmen, oder gar Produktivcode posten.
Das Konzept muss man einfach verstehen und anwenden, dann hat man recht schnell selbst den anspruchsvollen Code.

Aber ein Beispiel, Du hast eine Klasse "XYZ", welche Daten eines Typs überprüft - sie kennt deren Struktur und Anforderungen. Diese Klasse (nennen wir sie auch einen Service), weiß nicht, was mit den Daten passiert, oder wo diese herkommen, bzw. gespeichert werden. Das wird durch andere Klassen erledigt. Zugriff auf diese Klassen wird Dir über Interfaces (Schnittstellen) erklärt. Wenn Du Daten lesen/speichern musst, dann holst Du Dir den gerade implementierenden Service heran und mittels der Schnittstelle kannst Du diese Daten laden und speichern. Dieses Klasse XYZ interessiert jetzt aber nicht, ob die Daten aus einer XML Datei kommen, einer Datenbank oder aus dem TKitchenSink. Wozu auch, evtl. willst Du dem Anwender die Auswahl dazu überlassen. Am Ende muss aber jede Implementierung die Methoden zum Laden und Speichern anbieten und fertig ist's.

Und ein anderer Service implementiert die Verarbeitung der Daten (z.B. Druck, Darstellung, ...) und greift auf den Service (implementiert durch XYZ) zu. Dieser Service weiß jetzt, dass die Daten garantiert korrekt sind. Diesen interessiert nicht, wo diese herkommen, oder ob es diese überhaupt gibt. Aber wenn es diese gibt, dann sind die korrekt. Und wenn welche gespeichert werden sollen, dann wird sich XYZ schon darum kümmern, mich zu informieren, ob diese korrekt sind...

Dazu verwendet man i.A. Interfaces. Referenzzählung, autom. Freigabe, etc. sind nette Extras, aber nicht der Grund.

...:cat:...

[sakura]

Ein weiteres Stichwort wäre noch: Dependency Injection
Und: Unit Tests
Inkl. Mocking

...:cat:...

[himitsu]

Es gibt halt ein paar bekannte Dinge, wo sie verwendet werden:

* automatische Speicherverwaltung
gibt sich selbst frei, wenn nicht mehr benutzt

* Austauschbarkeit, siehe sakura
das Interface ist gleich, aber was runter ist, muß es nicht sein und dem Nutzer braucht es nicht zu interessieren
z.B. ein Einstellungenspeicherinterface, was auf INI, CSV, Datenbank, Registrie, Webservice oder ... geht
oder wo drunter je nach Zielsystem für Android/Linux/iOS/Windows/... die Behandlung anders ist

* nachträgliche Verbindung
z.B. das "einheitliche" Verhalten für datensensitive Komponenten zugreifbar machen
TDBEdit und TDBCheckbox sind nicht voneinander vererbt, bzw. bekommen ihre Datenbindung erst am Ende ihrer Vererbungshierarchie

* in Richtung COM-Interfaces (vermutlich der Ursprng der Delphi-Interfaces)
da wird es und Anderem als Schnittstelle zu Objekten benutzt, welche sich außerhalb deines Programms befinden

* ...

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1468022)

Meine Bitte war, anhand von anspruchsvollem, realem Code konkret den Nutzen der dort verwendeten Interfaces aufzuzeigen und mir (und anderen) verständlich zu machen.

Das ist in der Tat ein Problem. Selbst wenn jemand seinen anspruchsvollen, realen Code zeigen würde, bedürfe es vermutlich eines gehörigen Aufwands, konkret den Nutzen der dort verwendeten Interfaces aufzuzeigen und dir (und anderen) verständlich zu machen. Manchmal liegt die Rechtfertigung für Interfaces ja nicht mal im lokalen Anwendungsfall, sondern im großen Drumherum. Dazu müsste man ja auch einen Großteil der Architektur des gesamten Programms erklären. Zumindest ich selbst hätte dazu weder die Muße noch die Zeit.

[Benmik]

Zitat:

Zitat von sakura (Beitrag 1468025)

Das wird eher nicht passieren, da dieser Code meist "anspruchsvoll" ist. Dafür wird sich kaum einer die Zeit nehmen, oder gar Produktivcode posten.

Zitat:

Zitat von Uwe Raabe (Beitrag 1468029)

...bedürfe es vermutlich eines gehörigen Aufwands... Zumindest ich selbst hätte dazu weder die Muße noch die Zeit.

Das verstehe ich. Manchmal hat man ja Glück und irgendwen packt der Ehrgeiz. AsyncCalls und Omnithread sind ja auch sehr bekannt und manch einer hat sich den Code schon früher mal angeschaut.

Auf der anderen Seite geht es mir ja auch gar nicht darum, in die Tiefen dieser Units einzusteigen. Ich dachte halt, jemand sieht sich die Interfaces und die Implementierungen an und hat dann ein grobes Bild, unabhängig davon, was die Implementierung dann konkret macht.

Ich kann mir auch vorstellen, dass ein lakonisches Fazit lautet: Kann man mit Interfaces machen, muss man nicht. Sir Rufo beispielsweise stand ja im Ruf, alles mit Interfaces zu machen, was bei Drei nicht auf dem Baum war. Für den Fall, dass jemand sagt: Schau mal, hier ist das Interface X, und da die Implementierungen A, B und C, und als Klasse wäre das nicht so einfach/günstig, dann wäre das für meinen Durchdringungsprozess toll gewesen.

[freimatz]

Zitat:

Zitat von sakura (Beitrag 1468026)

Ein weiteres Stichwort wäre noch: Dependency Injection
Und: Unit Tests
Inkl. Mocking

An die dachte ich gerade auch. Und macht man nicht Dependency Injection wegen unit-tests (nicht zu verwechseln mit dunit / Integrationstest)? Hauptgrund bei mir interfaces einzusetzen ist DI .

Zu Dependency Injection wegen unit tests gibt es im inet tonnenweise - leider kaum was für Delphi. (Da sind leider zu viele Basterler unterwegs.)

Zitat:

Zitat von Benmik (Beitrag 1468030)

Sir Rufo beispielsweise stand ja im Ruf, alles mit Interfaces zu machen, was bei Drei nicht auf dem Baum war.

Bei uns in der Firma bekommen ca. 90% der neuen Klassen ein interface.

[QuickAndDirty]

@Benmik:
Interfaces sind sehr hilfreich, wenn ich Programmteile vor einander Verbergen will.
Wenn ich Programmteile von einander möglichst stark logisch trennen will und zwar so starke das ich den einen Programmteil kompilieren kann ohnde das der andere überhaupt auf der Festplatte liegt.
Sprich IInterface Nachfahren eignen sich zum definieren von Schnittstellen ohne das dabei Typ Abhängigkeiten entstehen.

Beispiel wäre ein klassisches MVC oder MVP Entwurfsmuster.
IVIEW könnte eine Windows-Oberfläche sein oder Userinterface das auf natürlicher Sprache basiert oder ein Proxy.
Wer auch immer meine IVIEW entwickelt es kann mir total egal sein, weil ich einfach nur das Interface bediene.

Es macht sinn!

Ich weiß nicht ob das mit den neuen records auch funktioniert... aber ich habs immer mit interfaces gemacht!

Außerdem braucht man Interfaces für Kompatibilität zu Windows Com-Objekten und natürlich für JNI.

[Benmik]

Zitat:

Zitat von QuickAndDirty (Beitrag 1468035)

Es macht Sinn!

Ich habe ja keinerlei Zweifel, dass es Sinn macht! Nur sind in aller Regel die genannten Anwendungsbereiche außerhalb meiner Einzel-Bastel-Sphäre. AsyncCall und Omnithread sind abgeschlossene, überschaubare Entitäten, die dennoch (?) Interfaces haben, und da habe ich gedacht, anhand dieser - zweifellos professionellen - Codeteile könnte ich dem Verständnis und eventuell sogar einem eigenen Einsatz näher kommen, sofern mir klar wird, dass es etwas für mich bringt. Im Moment ist mir das nicht klar; und ich weiß nicht, ob das daran liegt, dass bei mir Interfaces nicht sinnvoll eingesetzt werden können, oder daran, dass ich nicht sehen kann, wo es sinnvoll wäre.

[stahli]

@Benmik

Das ist eigentlich normal.

Irgendwann wird es "Klick" machen. Ab besten durch die Praktische Verwendung.

Ich stelle Dir einfach mal eine Aufgabe:

Erstelle insgesamt 100 Objekte von insgesamt 5 Klassen (direkt von TObject abgeleitet).
Jede Klasse soll eine Eigenschaft Value haben.
Eine vom Typ Boolean, String, Real usw.
Die 100 Objekte sammelst Du in einer Liste.
Die Liste übergibst Du einer Funktion Logging.
In Logging rufst Du für jedes Objekt dessen Methode Log auf.
In Log gibst Du den Wert aus Value immer als String aus.

Zwei Besonderheiten:
1) Du darfst in Logging nicht die Objekte casten.
2) Du darfst die Objekte nicht freigeben und dennoch keinen Memoryleak erhalten.


Man muss m.E. einfach damit arbeiten, um den Zweck zu verinnerlichen.

Aber man muss es auch nicht erzwingen. Wenn sich Dir der Zweck (noch) nicht erschließt, dann brauchst Du es eben nicht.
Immer wenn man Objekte castet, könnte das ein Indiz für die Sinnhaftigkeit von Interfaces sein.

Man hat letztlich eher eine Funktionalität, mit der man arbeitet. Die Classen spielen dann nicht mehr die Rolle, sondern funktionelle Einheiten.
Im obigen Beispiel ist das die Funktion "Log".

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1468027)

Es gibt halb ein paar bekannte Dinge, wo sie verwendet werden:

* automatische Speicherverwaltung
gibt sich selbst frei, wenn nicht mehr benutzt

* Austauschbarkeit, siehe sakura
das Interface ist gleich, aber was runter ist, muß es nicht sein und dem Nutzer braucht es nicht zu interessieren
z.B. ein Einstellungenspeicherinterface, was auf INI, CSV, Datenbank, Registrie, Webservice oder ... geht
oder wo drunter je nach Zielsystem für Android/Linux/iOS/Windows/... die Behandlung anders ist

* nachträgliche Verbindung
z.B. das "einheitliche" Verhalten für datensensitive Komponenten zugreifbar machen
TDBEdit und TDBCheckbox sind nicht voneinander vererbt, bzw. bekommen ihre Datenbindung erst am Ende ihrer Vererbungshierarchie

* in Richtung COM-Interfaces (vermutlich der Ursprng der Delphi-Interfaces)
da wird es und Anderem als Schnittstelle zu Objekten benutzt, welche sich außerhalb deines Programms befinden

* ...

Zusätzlich dazu sehe ich Interfaces hauptsächlich als Vertrag, für die Schnittstelle des Objektes.
Was dahinter vorgeht, geht mich nichts an.