Hallo,

ich habe mich gerade ein wenig mit Interfaces befasst. Ich überlege, ein vorhandenes und recht großes Projekt auf Interfaces umzustellen.

Meine Frage ist jetzt: Ist es möglich - ohne große Risiken und ohne sehr großen Aufwand - ein ganzes Projekt auf Interfaces umzustellen. Und wenn ja, lohnt es sich?

Ich überlege deshalb, weil ich geplant habe, ein Plugin-System für das Projekt zu entwickeln um die exe zu verkleinern. Das sollen DLLs sein und teilweise auch Forms enthalten. Ich weiß noch nicht, ob ich die Plugin-Schnittstelle (das Interface) veröffentlichen möchte. Es sind alles nur Gedanken.

Ich hoffe, ihr könnt mich dahingehend etwas beraten. Mit Plugin-DLLs und darin enthaltenen Forms habe ich Erfahrung. Diese setze ich bereits in zwei Projekten ein, ohne Probleme.

Danke!

Mit konkreten Erfahrungen kann ich nicht aufwarten. Aber die beiden Threads könnten interessant für Dich sein:
http://www.delphipraxis.net/166192-s...r-dummies.html
http://www.delphipraxis.net/166899-i...eferenzen.html

Ich sehe 2 Vorteile bei der Verwendung von Interfaces (in Delphi)
- die Speicherverwaltung ist automatisiert
- die Units Klassen sind deutlich besser voneinander entkoppelt

Als Nachteil ist sicher die erhöhte Schreibarbeit und ein gewisser Lernbedarf am Anfang zu nennen.

Ein "normals Projekt" auf Interfaces umzustellen, dürfte sich lohnen, wenn man sehr komplexe Beziehungen zwischen den Klassen herstellen muss und Probleme mit der Speicherverwaltung der Objekte hat. Mit Interfaces lässt sich das m.E. abstrakter und übersichtlicher handeln.

Wenn Du Objekte an eine DLL übergeben willst, geht das m.E. nur über Interfaces - stimmt das? Ich habe damit noch nie gearbeitet.

Solltest dir dies bzgl. auch mal die Serie von Nick Hodges anschauen. Ich finde, es lohnt sich wirklich. habe im Moment Spring im Einsatz und bin davon sehr überzeugt und freue mich jeden Tag aufs neue, wo schön Dinge doch sein können. Aber es Bedarf halt etwas an Verständnis für die Materie.

Aufwand und Risiken wirst du aber immer haben, da du ja ein sinnvolles Konzept erstellen solltest. Blind von jeder Klasse ein Interface definieren und loslegen hat imho nur den Vorteil der automatischen Speicherverwaltung. Hat man aber FastMM im Einsatz, so kann man das Problem der Speicherleichen aber schon von vorn herein bekämpfen. Beim Umstieg solltest du ruhig einen Schritt weiter gehen, imho.

@stahli: man entkoppelt nicht Units voneinander, sondern man schafft eine lose Kopplung. Klassen hängen nicht mehr direkt voneinandere ab, sondern eben nur noch von den definierten Schnittstellen, egal welche Klassen diese implementieren.

Die Frage ob ein vorhandenes Projket einfach und problemlos auf Interfaces umstellbar ist, ist nicht so einfach. Im Zweifel würde ich diese deshalb mit Nein beantworten

Klares "kommt drauf an". Hängt vom vorhandenen Design der Anwendung ab. Lässt sich diese ohne große Umbauten auf Interfaces umstellen, ohne dass du in AVs und invalid pointer Exceptions rennst, weil das ganze Lifetime Management deiner Instanzen so vertrackt ist.

Bei der Benutzung von Interfaces musst du dir auch im Klaren darüber sein, wie das Interface aussehen soll und ob du bei einem Plugin System abwärtskompatibel sein möchtest so dass nicht alle Plugins bei einer Erweiterung/Änderung des Interfaces neu erstellt werden müssen. Wie sehen die Signaturen deiner Interface Methoden aus. Benutzt du dort eigene Typen, sollten diese eventuell in ein Package.

Auch die VCL und jegliche TComponents vertragen sich nicht immer mit Interfaces, da ihr Lifecycle nicht über die Interface Referenzzählung gesteuert wird, sondern über den Owner. Das kann schnell zu AVs führen (TComponent wird über den Owner Mechanismus freigegeben, aber eine Interface Referenz auf diese Komponente ist noch irgendwo vorhanden).

Dass die Interface Referenzzählung nicht mehr greift, wenn man sich überkreuzende Referenzen hat (Parent/Child Relation z.B.), sollte man auch beachten.

Ich selber mag Interfaces sehr gerne, da sie einem ein gutes Stück eine Art GC vorgaukeln, aber man sollte über die Gefahren im Klaren sein und darüber dass in der Theorie immer alles ganz einfach gesagt ist "always code against interfaces" aber in der Praxis nicht immer realisierbar.

Forms in DLLs auslagern ... da muß man aber auch etwas aufpassen.

Hallo.

Vielen Dank für die zahlreichen Antworten. Nach alldem habe ich mich entschlossen, das mit den Interfaces etwas aufzuschieben und das Projekt erstmal so zu warten. Dann, wenn ich mehr Zeit habe, werde ich mit Interfaces neu (parallel) entwickeln und dann die "alte Version" aufgeben.

Aber ich werde mich damit dann doch noch beschäftigen, nur halt später.

Vielen Dank

Wenn es dir nur um die Größe geht, dann kannst du es notfalls auch mit Laufzeitpackages versuchen.

Danke für den Tipp. Es geht mir nicht nur um die Größe, aber sie spielt auch eine Rolle

Das Programm nutzen recht viele Leute, da werde ich lieber erstmal genau überlegen, was ich will und mich nochmal genau über Interfaces informieren. Ich weis ja momentan noch nichtmal, ob ich wirklich ein Plugin-System entwickeln will.

Ich denke lieber nochmal nach. Wenn ich in ein paar Wochen wieder mehr Zeit habe, dann weis ich bis dahin bescheid, was ich will und werde dann ggf. parallel entwickeln.

Danke

Wobei die Interfaces nicht die einzigen Dinge sind, worüber du nachdenken mußt.

Auch alles, was über dieses Interfaces hin- und hergereicht wird, muß berücksichtigt werden.

VCL-Komponenten über DLL-Grenzen hinweg zu behandeln könnte Probleme bereiten,
auch auf andere Objekte oder Strings muß man aufpassen,
vorallem da standardmäßig der Speichermanager und die RTTI nicht gemeinsam verwaltet werden.

Ausschließlich der WideString kann problemlos übergeben werden, da dieser nicht vom Delphi verwaltet wird, sondern global über die WinAPI (SysAllocString und Co.).
Er steht damit sogar in C und anderen Sprachen zur Verfügung.
Auch Records und statische Arrays, aus einfachen Typen, sind problemlos möglich.