Projekt auf Interfaces umstellen

[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.

[neo4a]

Zitat von 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.

Schon klar. Nur habe ich den beschriebenen Ansatz auch bereits recht erfolgreich bei Alt-Projekten einsetzen können. Dabei ging es insbesondere um die Entflechtung von zusammengeklickten Komponenten verschiedener Libs.

Ein angestrebtes Maß dabei war z.B., dass keine Unit mehr als 1000LOC umfasst.

Für mich persönlich war diese Herangehensweise (also ausgehend von einem Bestands-Projekt) auch deshalb sehr positiv, weil ich mich nicht so sehr auf Programm-Features und UI-Design konzentrieren musste, sondern ganz gezielt mittels CleanCode-Prinzipien und Design-Pattern den ziemlich typischen Delphi-Klick-Code zerlegt habe. Als ich den Bogen raus hatte, machte es nicht nur Spaß, sondern ging auch ziemlich flott.

Im Gegensatz zu der hier schon häufig gelesenen Ankündigung, es beim nächsten Projekt "richtig" anzugehen, glaube ich da nicht so dran: Neue Projekte gleichzeitig mit neuen Ansätzen ohne belastbare Erfahrung anzusetzen, ist m.E. fahrlässig und dürfte meistens in der einen oder anderen Form scheitern.

[Stevie]

Ehrlich gesagt, würde mir der Ansatz nicht gefallen, weil ich es ehrlich gesagt hasse, wenn man seine UI zur Laufzeit erzeugt und man keine Möglichkeit hat, sich mal ebend im Designer anzuschauen, wie das Form aussieht und/oder mal ebend was verschiebt etc.

Ich kenn das aus unserem Produkt, dort gähnt einen im Designer ein leeres graues Form an, welches zur Laufzeit zig verschiedene Komponenten enthält.

Genau aus diesem Grunde habe ich ja beim DSharp MVVM Ansatz versucht, beide Konzepte unter einen Hut zu bringen. UI zusammen klicken, aber keine Events oder sonstiges implementieren, sondern im ViewModel machen, welche dann gebunden werden.

[sx2008]

Wenn man Interfaces einsetzt muss man gleichzeitig auch einen Preis dafür bezahlen.
Man muss die Methoden nicht nur im Interface deklarieren, sondern auch in den Klassen nochmals mit genau gleicher Signatur deklarieren.

Das mag auf den 1. Blick noch kein Problem darstellen; man muss ja nur die Methoden aus dem Interface kopieren und in die betroffenen Klassen einfügen (per Copy & Paste).
Es baut sich aber ein gewissen psychologischer Widerstand gegen das Ändern von Interfaces auf.
"Eigentlich müsste ich ja noch eine weitere Funktion in das Interface XY einbauen, aber dann muss ich das in 5 weiteren Klassen nachziehen. Da hab' ich gerade keine Zeit dafür, drum lass ich es lieber mal so wie es ist"

Daraus kann man den Schluss ziehen, dass wenn man Interfaces verwendet, sollte man dies sehr sorgfältig tun.
Wenn man z.B. Methoden in ein Interface aufnimmt, die später eigentlich gar nicht gebraucht werden, dann ist das auch verschwendete Arbeit und ein Störfaktor im Sourcecode.

Als Delphi-Programmierer muss man aber noch einen weiteren Preis bezahlen; das leidige Thema mit der Referenzzählung von Interfaces.
Sobald man ein Objekt über ein Interface anspricht, hat man die Verantwortung für die Lebensdauer praktisch an die Referenzzählung abgetreten.
Danach darf oder sollte man das Objekt nicht mehr über die normale Objektvariable ansprechen.
Es gibt da Dinge die das Programmieren im gemischten Umfeld von Interface-Zeigern und Objekt-Zeigern nicht gerade einfach machen.
Ein .NET-Programmierer hat es da viel einfacher (*), da Objekt- und Interface-Referenzen unter .NET einer gemeinsamen Garbagecollection unterliegen.

Fazit:
Interfaces sind eine gute Sache, wenn man sich der Vor- und Nachteile genau bewusst ist.
Ein Projekt "auf Interfaces unzustellen" macht keinen Sinn;
wenn man aber gezielt neue Interfaces einführt (z.B. für Plugins) und weiss was man tut
ist man auf dem richtigen Weg.

*) neidisch kuck

[himitsu]

Zitat von sx2008:

Es baut sich aber ein gewissen psychologischer Widerstand gegen das Ändern von Interfaces auf.

Interfaces ändert man nicht, vorallem nicht, wenn sie über Modulgrenzen hinweg und/oder gar von anderen Personen/Programmen (z.B. Plugins) verwendet werden.

Man könnte sie manchmal noch erweitern, aber besser währe dann eine Vererbung und das Neue Interface unter anderem Namen zu veröffentlichen.

Ganz schlimm wäre es, wenn sich parameter ändern, dann kommt es garantiert zu Problemen, also wenn man bestehende Funktionen ändert.
(Neues hinten dran = weniger/kein Problem)

[stahli]

Zitat von sx2008:

Das mag auf den 1. Blick noch kein Problem darstellen; man muss ja nur die Methoden aus dem Interface kopieren und in die betroffenen Klassen einfügen (per Copy & Paste).
Es baut sich aber ein gewissen psychologischer Widerstand gegen das Ändern von Interfaces auf.
"Eigentlich müsste ich ja noch eine weitere Funktion in das Interface XY einbauen, aber dann muss ich das in 5 weiteren Klassen nachziehen. Da hab' ich gerade keine Zeit dafür, drum lass ich es lieber mal so wie es ist"

Mir wird immer bewusster, dass, wenn man sich Arbeit sparen will und man etwas "mal eben auf dem kurzen Wege" löst, man dies später irgendwann mit deutlich mehr Aufwand wieder korrigieren muss.
Also mehr Tippaufwand würde ich für eine übersichtlichere Projektstruktur inzwischen immer in Kauf nehmen (jedenfalls für ein ernsthaftes Projekt).
Deshalb erscheinen mir Interfaces inzwischen auch reizvoll.

Zitat von neo4a:

Im Gegensatz zu der hier schon häufig gelesenen Ankündigung, es beim nächsten Projekt "richtig" anzugehen, glaube ich da nicht so dran: Neue Projekte gleichzeitig mit neuen Ansätzen ohne belastbare Erfahrung anzusetzen, ist m.E. fahrlässig und dürfte meistens in der einen oder anderen Form scheitern.

Falls ich (u.a.) gemeint bin: Natürlich werde ich einige Tests durchführen und mich an das Thema heran tasten. Da ich jetzt schon eine ganz gute Projektstruktur habe, halte ich einen Neuaufbau mit Interfaces für durchaus machbar. Die Daten und die GUI blieben gleich. Das Framework darum müsste erneuert werden. Jedenfalls freue ich mich schon drauf und inzwischen habe ich ja auch schon diverse Ansätze durch und ein paar Erfahrungen gemacht.