Schon wieder: Warum Interfaces

[exilant]

Ich muss mich mal outen: Seit vielen Jahren entwickle und pflege ich mit Delphi eine ziemlich umfangreiche Branchenanwendung (In House, neuerdings mehrere Standorte). Nach Ausflügen zu C# und PHP/Javascript bin ich doch immer wieder bei Delphi gelandet. Jetzt steht die Modernisierung vieler älterer Module an und ich beschäftige mich seit Tagen intensiv mit Interfaces. Bisher ein weißer Fleck auf meiner Delphi Landkarte.

Ja: Auch im Jahre 2016 AD gibt es es immer noch Entwickler die mit „plain old delphi objects“ coden.
Nun gehe ich mal davon aus, dass all‘ die Delphi-Gurus hier und anderswo nicht aus rein modischen Gründen und nicht erst seit gestern die Verwendung von Interfaces immer und überall bevorzugen sondern gute Gründe dafür haben.

Ich habe dazu mehrfach den Abschnitt in Nick Hodges Buch (Coding in Delphi) zu dem Thema gelesen. Ein großes Plädoyer für die Programmierung mit Interfaces. Weiterhin habe ich gegoogled was das Zeug hält und auch viele Beiträge hier im Forum durchgeackert. Ich habe mir selbst mal ein paar Interfaces gebastelt und damit gespielt. Lange Rede, kurzer Sinn: Ich glaube prinzipiell verstanden zu haben wie Interfaces funktionieren auch wenn ich einige hiesige Forumsbeiträge zum Thema keineswegs verstanden habe.
Bei vielen verstehe mitunter nicht mal über welches Problem geschrieben wird. Offensichtlich sind es jedoch manches Mal Probleme die man ohne Interfaces nicht hätte. Das „reference counting“ finde ich z. B. nach meinem derzeitigen Verständnis von interfaces gelinde gesagt sche.. ääh nicht gut.

Wie dem auch sei: Der Knackpunkt bei der Frage nach dem Einsatz von Interfaces ist für mich das „Warum“. Darauf habe ich nirgendwo eine befriedigende Antwort bekommen. Ich zitiere mal (ich hoffe, das ist OK) eine Passage aus dem Text von Nick Hodges, (Buch „Coding in Delphi“, Blog) aus dem Abschnitt
„Why Do You Want To Use Interfaces?“ um mein Problem zu verdeutlichen:

Zitat:

Nick Hodges, Blog Coding in Delphi
[...]Say you have a large system with different teams working on different major modules.* Those teams are responsible for providing functionality in their own modules, and thus they are responsible for the integrity and quality of the code in their modules.* Let’s say you are on the Widget team, and you need the Sprocket team to do something for you.* You go to the Sprocket guys and say “Hey, I need to add a few things in the Sprocket code so that we can do some Sprocket-type stuff in our Widget.”* The Sprocket guys are going to laugh at you – like they are going to let you poke around in their carefully crafted system!* No, instead, they will likely ask you want you need, build the functionality, and hand you some code with an interface and a factory for creating an implementation of that interface.* They aren’t going to let you anywhere near their code – but they are happy to let you have an interface into that code.* You get what you want – some Sprocket functionality – and they don’t have to expose anything more than an interface to you.* And later, if they completely re-architect their code, what do you care?* Your interface still works, even if they completely change the internal implementation.* That’s a sound way to develop, all made possible because of interfaces....

Das folgende Staement irritiert mich außerordentlich:

Zitat:

..Your interface still works, even if they completely change the internal implementation.* That’s a sound way to develop, all made possible because of interfaces.

Nochmal: „...all made possible because of interfaces.“????? Das gilt so auch für Klassen. Warum soll das oben beschriebene Widget/Sprocket Problem durch Interfaces erst lösbar sein? Ich hantiere (wie viele andere) alltäglich mit Klassen, über deren Implementierung ich nichts weiß, nichts wissen will und auch nichts wissen muss. Das ist doch ein wesentliches Merkmal von klassischer OOP.

Aber dann natürlich

Zitat:

If you choose not to embrace interfaces, then you are locking yourself out of new and effective programming frameworks and techniques.* Or, put another way, all the cool kids are doing interfaces, and you want to be part of the cool kid group, right?

Ja. ich will zu den coolen Kids gehören. Ich ahne, dass da was ist was ich nicht sehe. Und damit komme ich zum Schluss und zu einer konkreten Bitte: Kann mir irgendwer hier ein Beispiel, entsprechende Links oder Literaturempfehlungen posten denen ein durchaus erfahrener, aber mit Interfaces nicht vertrauter Entwickler entnehmen kann worin der Nutzen von Interfaces gegenüber einer „normalen“ Hierarchie aus (auch abstrakten) Klassen liegt. Was kann ich damit exklusiv tun? Und wenn nicht exklusiv, dann zumindest einfacher oder besser. Vermutlich sind all‘ die Beispiele die ich bisher gelesen habe zu trivial. Zu komplexe waren allerdings auch dabei. Ich erkenne einfach den Nutzen von Interfaces immer noch nicht. Lasst mich nicht dumm sterben!

[stahli]

Nettes Thema

Ich hatte mal etwas dazu zusammen gestellt: http://www.delphipraxis.net/183702-i...-factorys.html

Also ich würde mal 3 Punkte aufzählen:
+ Entkopplung
+ Austauschbarkeit
+- Referenzzählung


Entkopplung:

Wenn Du ein TAuto konstruierst, musst Du ein TMotor, TLenkrad und TRad benutzen und diese irgendwo verbinden.
Dazu musst Du bei der Verwendung von Klassen die kompletten Units kennen und einbinden.
Wenn der Motor jetzt z.B. wissen müsste, in was für einem Auto er steckt und ob das Auto gerade auf einem Prüfstand fährt , dann muss TMotor u.U. TAuto kennen.
So hat man schnell überkreuzende Referenzen und muss sehen, dass man diese Probleme irgendwie löst.
Auch hat man indirekt ziemlich viel Ballast (in Form von Klassenmembers), den man später gar nicht braucht.

Wenn Du mit Interfaces arbeitest, kannst Du das leichter abstrahieren.
Kurz gesagt, man arbeitet nur noch mit dem Wesentlichen.

Es interessiert dann nicht mehr, wo und wie die Klasse deklariert ist. Ich habe etwas mit festgelegten Eigenschaften und Methoden und kann das benutzen ohne mich mit der ganzen Klasse befassen oder diese kennen zu müssen.


Austauschbarkeit:

Es gibt ein Auto, einen Motor, Lenkrad und Räder. Was das genau für Räder sind, Luftbereift, Vollgummi oder was auch immer spielt keine Rolle.

Wenn so ein Rad eine bestimmte Aufnahme auch wieder als Schnittstelle beinhaltet kannst Du später die Räder durch andere Klassen ersetzen (z.B. AntiGravitationsräder) wenn diese die gleiche Schnittstelle für die Räderbefestigung haben.

Auf "klassischem" Wege müsstest Du die neuen Räder von TRad ableiten, um dieses in der Autoklasse verwenden zu können. Wenn aber das neue Rad auch von TNeuesMaterial abgeleitet werden müsste, damit eine Werkstatt das herstellen kann, hat man ein Problem.

Mit Verwendung von Interfaces kann das neue Rad mehrere Erfordernisse unterstützen

TNewWheel = class(TInterfacedObject, IWheel, INewMaterial)

Jetzt kann die Werkstatt mit dem Objekt umgehen, da es NewMaterial ist und das Auto kann damit fahren, weil es ein Rad ist.

Man kann auch leicht DummyObjekte bauen, die erst einmal bestimmte Funktionen simulieren.
Wenn Du das mit echten Klassen machen willst, musst Du direkt in Dein Projekt eingreifen und das später wieder korrigieren.

Wenn Du mit Interfaces arbeitest, kannst Du leichter von außen ein DummyObjekt in Dein Projekt herein reichen, das so tut, als wäre es ein echtes Businessobjekt, aber intern einfach erst mal bestimmte Funktionen simuliert (und auch von einer völlig anderen Basisklasse abgeleitet ist).


Referenzzählung:

Das ist Fluch und Segen, aber auch optional.

InterfacedObjects in Delphi zählen mit, wie oft sie benutzt werden. Fällt die letzte Nutzung weg (indem einer Variablen z.B. Nil zugewiesen wird oder das Programm den Scope verlässt, in dem die Variable erzeugt wurde, dann wird das Objekt freigegeben.
Man muss bzw. darf daher für Interface-Variablen nie Free aufrufen. Statt dessen darf man Nil zuweisen, was aber beim Verlassen eines Scopes auch automatisch erfolgt.
Also man muss Interface-Variablen nicht freigeben, wenn man es will, dann nur durch Nil-Zuweisung.

Eigentlich ist das eine ganz nette Sache, aber es hat zwei Haken:
Wen ich in aMotor ein Motor-Interface habe und ich Nil zuweise (aMotor := Nil) kann es sein, dass das Objekt noch nicht freigegeben wird, weil irgendwo im Speicher möglicherweise noch ein Zugriff auf dieses Interface existiert (z.B. in einer Liste oder so).
Durch meine Nil-Zuweisung wird der RefCounter verringert (z.B. von 2 auf 1) und das Objekt aber erst bei 0 freigegeben.

Für die Liste existiert der Motor noch.
Wenn man mit Objekten arbeitet und hier aMotor.Free angegeben hätte, könnte es später bei Zugriff auf die Motoren-Objekte in der Liste knallen.

Bei Motoren-Interfaces in der Liste knallt nix, da das Objekt noch nicht freigegeben wurde.

Wenn ich aber vorhin das Objekt wirklich FREIGEBEN wollte, dann kann das Projekt den Motor noch verwenden, der eigentlich aber nicht mehr existieren sollte.

Ok, welche fehlerhafte Arbeit des Projektes ist die schlechtere? Das kann man so nicht entscheiden. Wichtig ist, dass man bei Vewrwendung von Interfaces mit Referenzzählung beachten muss, dass man nicht ohne weiteres in der Hand hat, wann das Objekt tatsächlich freigegeben wird.


Noch komplizierter wird es bei gegenseitigen Referenzen.
Man stelle sich vor, das Moterinterface würde das Interface der Liste kennen, in der es steht.
Jetzt entfällt von außen der letzte Zugriff auf die Liste und der RefCounter wird reduziert und läuft auf 0.
Die Liste wird automatisch freigegeben...

...wäre schön, aber klappt nicht, da das MotorInterfaceobjekt in der Liste ja eine Referenz auf die Liste hält.
Der RefCounter der Liste kann also durch Maßnahmen von außen nur auf 1 fallen. Also wird die Liste nie aufgelöst.
Auch das MotorInterfecedObjekt wird nie aufgelöst, da es ja von der Liste referenziert wird.

In solchen Fällen muss man dann selbst für das Aufräumen sorgen.
Man könnte für die Liste Clear aufrufen, wodurch die Referenzen auf die Items entfallen und auch die Referenz des Motors auf die Liste entfällt und alles freigegeben wird.

Dies braucht aber eine explizite Veranlassung.

Dennoch ist die Referenzzählung eine ganz angenehme Handhabung. Man muss aber berücksichtigen, dass es insgesamt ein anderes Handling ist.

Man kann allerdings auch Interface-Objekte ohne Referenzzählung verwenden.
Dann bestimmt man die Lebenszeit der Objekte weiterhin selbst, kann aber Objekte weiterhin leichter austauschen.
Das währe dann ähnlich einem Cast zu sehen.

Wenn man klassisch verschiedenste Objekte einer Methode übergeben will

Delphi-Quellcode:

uses
  ...alle Units, die ein fahrbares Objekt deklarieren...

procedure Fahre(O: TObject)
begin
  if (O is TAuto) then
    (O as TAuto).Fahre;
  if (O is TFahrrad) then
    (O as TFahrrad).Fahre;
end;

müsste man in der Methode das Objekt in TFahrrad oder TAuto casten.

Mit Interfaces könnte man folgendes deklarieren:

Delphi-Quellcode:

uses
  MyInterfaces;

procedure Fahre(FahrbaresObjekt: IKannFahren)
begin
  FahrbaresObjekt.Fahre;
end;

[Aviator]

Also mich interessiert die Frage ja auch brennend. Ich habe noch nie wirklich einen überzeugenden Grund gefunden, der was "Wieso" beschreibt.

Ich würde unheimlich gerne mit Interfaces arbeiten und habe auch schon das eine oder andere Mal meine Klassen mit einem Interface aufgebaut. Aber oft sehe ich einfach nicht die Notwendigkeit. Ich arbeite nie im Team sondern immer alleine. Somit muss ich mit niemandem meinen Code teilen.

Aktuell habe ich ein Projekt, bei dem ich eine Schnittstelle nach außen bringen muss. Hierzu programmiere ich mehrere DLLs. Dort bieten sich Interfaces natürlich extrem gut an. Und dort verstehe ich auch das "Wieso".

Meine DLL muss nur noch eine Methode exportieren. Und zwar eine (ich nenne sie immer so) GetInstance Methode, welche mir eine Instanz zu einem Interface liefert. Der Vorteil ist der, dass ich das Interface nur einmal definieren muss und kann es jedem zur Verfügung stellen. Somit entfällt diese ganze Schreiberei für denjenigen, der die DLL benutzen will. Auf der anderen Seite würde derjenige der die DLL nutzt, nur die Methoden in sein Programm aufnehmen, welche er wirklich auf verwenden will.

Das Interface bei der DLL hat eben noch den Vorteil (im Vergleich zu normal exportierten Methoden), dass dahinter eine Klasse stehen kann, welche direkt angesprochen wird. Mit Objekten ist das ja so eine Sache. Das funktioniert da ja dann nicht so einfach. Und die Klasse im Bezug auf Interfaces hat eben den Vorteil, dass da instanzspezifisch Daten gespeichert werden können welche dann auch nur über spezielle Interfacemethoden wieder abgerufen werden können.


Nur wenn ich eine Klasse schreibe die genau eine Aufgabe hat und ich weiß, dass da niemals mehr etwas hinzu kommt, dann erschließt sich mir der Sinn eines Interfaces einfach nicht.

Klar, die Referenzzählung ist eine schöne Sache. Man muss einfach nicht mehr auf das Object.Free achten. Aber das ist so drin bei mir, dass ich das eigentlich nie vergesse. Und wenn doch, dann schreit ReportMemoryLeaksOnShutdown nach Hilfe.

@Stahli: Nichts für Ungut, aber ich sehe mich was Interfaces angeht auf einem leicht höheren Level als den TE. Und ich finde deine Beispiele doch recht schwierig zu verstehen. Ich hatte damals den Thread von dir (den du ja auch wieder verlinkt hast) aufmerksam verfolgt. Eben weil mich das Thema Interfaces so interessiert und ich mich weiterbilden will. Durch das Thema bin ich damals zwar durchgestiegen, aber es wurde auch nie wirklich ein "Wieso" Grund genannt, welcher mich überzeugt hätte.

Das soll jetzt auf keinen Fall böse wirken oder so.


Sir Rufo ist doch unser Interface Spezialist hier. Er macht doch für alles und jeden ein Interface. Vielleicht hat er ja einen alles übertreffenden Grund parat. Leider hat er schon länger nichts mehr hier geschrieben.

Ich hoffe meine Antwort (obwohl ich nahezu so unwissend bin wie der TE) hat dem TE und/oder anderen Lesern die vor dem gleichen Problem stehen trotzdem ein wenig geholfen.

[Luckie]

Zitat von Aviator:

Sir Rufo ist doch unser Interface Spezialist hier.

Sir Rufo IST ein Interface.

[Mavarik]

Also DLL geht bei mir so:

Delphi-Quellcode:

Procedure SetInterface(Var DLL:IGoogleMapsDLL);
begin
  DLL := TGoogleMaps.Create;
end;

Exports
  SetInterface;

So compiliere ich eine Unit mit dem TMS-Google Maps Komponenten in eine DLL, die ich dann problemlos von D2007 aus nutzen kann.

Und das Fenster wird in der DLL erzeugt:

Delphi-Quellcode:

function MapInit(ParentWnd: hwnd; R: TRect): hWnd; : hwnd;
begin
  FGoogleMapForm := TGoogleMapForm.CreateParented(ParentWnd);
  FGoogleMapForm.Layout.Height := R.Height;
  FGoogleMapForm.Layout.Width  := R.Width;
  FGoogleMapForm.Layout.Realign;
  FGoogleMapForm.Init;(Mini,Internet,DIP91,MapStreetLevel);
  SetWindowPos(FGoogleMapForm.Layout.Handle,0,R.Left,R.Top,R.Right-R.Left,R.Bottom-R.Top,0);
  Result := FGoogleMapForm.Layout.Handle; //Frame.Handle;
end;

Fertig... So brauche ich in D2007 weder einen Link zu den TMS Units, noch muss ich wissen was die machen... Auch keine Komponenten installieren.

uvm...

Zum Beispiel linke ich so eine PDF DLL bei der ich die Units nur im XE6/DCU Format habe gegen jede Delphi Version...

Hierzu mache ich/wir "die Tage" noch einen Workshop...

[DeddyH]

Und das hat genau was mit Interfaces zu tun?

[edit] Um noch etwas Konstruktives beizutragen:
- Bei der Verwendung von Interfaces muss keine bestimmte Klassenhierarchie eingehalten werden, da der Verwender lediglich das Interface sieht und nicht die dahinterstehende Klasse.
- Interfaces können modulübergreifend (Anwendung <-> DLL) verwendet werden, im Gegensatz zu Objekten (OK, das ginge mit BPLs, die sind aber versionsabhängig).
- Eine Klasse kann beliebig viele Interfaces implementieren, damit erreicht man so etwas ähnliches wie Mehrfachvererbung.
- Bei Verzicht auf sprachspezifische Typen und/oder Konstrukte können Interfaces sprachunabhängig verwendet werden.

Mehr fällt mir spontan nicht ein, vielleicht meldet sich Stevie ja noch [/edit]

[Jasocul]

Ein Spezialist für Interfaces bin ich sicher nicht und ich nutze die auch nur rudimentär. Aber vielleicht bin ich deshalb der Richtige für das "wieso".
Ich stand auch mal vor dieser Frage und bin auf dieses Beispiel gestoßen.
Natürlich kann man das auch mit einer Basisklasse lösen, die entsprechende abstrakte Methoden verwendet, aber denkt man wirklich von Anfang an, an alle möglichen Dinge?
Es ist sicher möglich, die Basisklasse später zu ergänzen, ist in dem Fall aber gezwungen, auch alle Nachkommen anzupassen. Mit einem Interface kann man das auch einfach in den Nachkommen bei Bedarf machen.

Verwendet habe ich das zum Beispiel bei einer TreeView. Dort wurden viele Objekte eingebunden. Um die Darstellung zu vereinfachen, bekam jedes Objekt ein Interface mit Methoden, die mir eine vernünftige Bezeichnung liefern und bei Bedarf verschiedene Berechnungen machten. Durch das Interface waren alle Bezeichner einheitlich, egal, welches Objekt dahinter stand.
Auch das Problem kann man sicher klassisch mit OOP lösen, aber ich fand die Lösung mit dem Interface schon ziemlich praktisch.

[Ghostwalker]

Hi,

da ich mich auch grad mit Interfaces beschäftige ist das natürlich auch für mich interresant.

Ein (wie ich meine) gute Beschreibung findest du im "Delphi Developer's Handbook" von Marco Cantú.


Die Vorteile die ich darin sehe, sind folgende:

- Übersichtlichkeit

Selbst wenn man nur alleine Entwickelt, sammeln sich im laufe der Zeit einiges an Klassen
an. Wenn ich die später nutzen möchte, interressiert mich nicht, wie ich das implementiert
hab, sonder welche Methoden/Propertys ich habe und Was gemacht wird.

- Sprachunabhängigkeit

Du kannst Klassen auch in anderen Sprachen (C,C++,C# oder what ever) schreiben und in Delphi
nutzen.

- COM/COM+/DCOM

Die Nutzung dieser Windows-Techniken ist schlicht und ergreifend ohne Interfaces nicht möglich,
da das ganze System drauf beruht (z.B. Einbindung von Word, Excel usw.). Auch die Nutzung
von ActiveX-Komponenten wird dadurch erst möglich.

Fazit (für mich soweit):

Es gibt etliche Situationen, in denen Interfaces sinnvoll einzusetzen sind. Deshalb aber zwanghaft
überall Inferfaces einzusetzen wäre aber übertrieben.

[DeddyH]

Noch ein Vorteil: man kann seine Klassen quasi in einer Art Baukastenprinzip designen. Eine Klasse soll etwas bestimmtes können: entsprechendes Interface implementieren. Sie soll auch etwas anderes können: weiteres entsprechendes Interface implementieren. Auf Verwenderseite kann man dann einfach abfragen, ob ein Interface implementiert ist und dies dann nutzen.

[bra]

Der einzige Grund, wieso ich bisher bewusst ein Interface eingesetzt habe (von COM und sowas mal abgesehen), war, dass ich Mehrfachvererbung für eine Klasse brauchte. Ist mir bis heute unverständlich, wieso Delphi sowas nicht unterstützt.