Projekt auf Interfaces umstellen

[TheMiller]

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!

[stahli]

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.

[s.h.a.r.k]

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.

[mkinzler]

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

[himitsu]

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

[TheMiller]

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

[Stevie]

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.

[neo4a]

Zitat von Stevie:

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 lässt sich relativ elegant umgehen, indem man genau 2 Dinge tut:
- Das fragliche TComponent wird von einem TInterfacedObject verwaltet.
- Unser TComponent bekommt als Owner NIL oder einen "Langläufer" z.B. TAplication.Mainform

Delphi-Quellcode:

type

IMyVCLComponent = interface
  procedure SetParent(aParent : TWinControl);
end;

TMyVCLComponentObject = class(TInterfacedObject, IMyVCLComponent )
private
  FMyVCLComponent : TComponent;
private // IMyVCLComponent 
   procedure SetParent(aParent : TWinControl);
public
  constructor Create;
  destructor Destroy; override;
end;

implementation;

constructor TMyVCLComponentObject.Create;
begin
  FMyVCLComponent := TComponent.Create(nil);
end;
 
destructor TMyVCLComponentObject.Destroy;
begin
  FMyVCLComponent.Free;
  inherited;
end;

procedure TMyVCLComponentObject.SetParent(aParent : TWinControl);
begin
  FMyVCLComponent.Parent := aParent;
end;

Mit dieser Konstruktion lassen sich (VCL)-Komponenten auch leicht mittels Spring4D verwalten. Ein weiterer erwünschter Effekt ist die damit mögliche vollständige Entkopplung von Dritt-Units und/oder -Libs vom Hauptprogramm. Kein Licht ohne Schatten: Durch die erforderliche dynamische Erzeugung zur Laufzeit muss man auf den Delphi-Designer verzichten.

Zitat von Stevie:

"always code against interfaces"

Aber allein durch den Versuch, sehen die Programme gleich ganz anders aus

[Stevie]

Es ging um die Umstellung eines vorhandenen Programms auf Interfaces und nicht um den Start auf der "grünen Wiese" - und da lässt sich nicht alles mal so umsetzen.