Probleme bei Projektaufteilung in Packages

[OlliWW]

Hallo Zusammen,

Da mein Projekt nun schon sehr groß geworden ist, versuche ich gerade das Projekte in kleinere Packages aufzuteilen.

Mein größtes Problem dabei ist, dass viele Units logischerweise viele Abhängigkeien zu anderen Units haben und dies unheimlich schwer zu trennen ist.

Nun suche ich nach Wegen dies zu tun.

Viele Abhängigkeiten zu anderen Units könnte ich auflösen, wenn ich es schaffen würde bestimmte Aufrufe umzuprogrammieren.

Beispiel:
In meinem Package habe ich ein paar Stellen die eine Messagebox aufrufen. Dies ist eine spezielle Messagebox mit eigenen Anpassungen etc. Dies ist nur ein Methodenaufruf, der aber wiederrum Units aus dem Hauptprojekt nutzt.
Gibt es eine Möglichkeit diesen Methodenaufruf zu implementieren, ohne dabei zur Kompilierzeit des Packages die Funktion zu kennen? Ich bin mir nicht sicher, aber vielleicht könnte RRTI mir hier helfen?!

[Uwe Raabe]

In diesem Fall können Prozedurvariablen eine Hilfe sein. Etwas Ähnliches findest du in dieser Antwort auf StackOverflow: How to access delphi function at DPR scope

Im Wesentlichen deklariert man einen Prozedur- oder Methodentyp (in neueren Versionen auch den Typ einer Anonymen Methode), legt eine entsprechende Variable, ein Property oder einen Aufrufparameter an, der dann im Hauptprojekt mit der tatsächlichen Implementierung besetzt wird.

[OlliWW]

Hallo,

Danke für die Antwort, ich hätte vielleicht noch dabei schreiben sollen, dass ich es schon mit Properties die proceduren sind versucht habe. Dies klappt auch wunderbar. Das Problem ist, dass mein "generelles" Package in vielen Units im Hauptprojekt genutzt wird (> 1000 Units) und ich deshalb bei jedem Objekt dieses Property zuweisen muss, was eine Menge Arbeit ist

[Uwe Raabe]

Dann verwende eine globale Variable. Das ist zwar eigentlich verpönt, aber deutlich weniger Arbeit. Wenn jetzt sowieso immer dieselbe Prozedur aufgerufen wird, ist die globale Variable faktisch auch nichts anderes.

[Mavarik]

Zitat von OlliWW:

Gibt es eine Möglichkeit diesen Methodenaufruf zu implementieren, ohne dabei zur Kompilierzeit des Packages die Funktion zu kennen? Ich bin mir nicht sicher, aber vielleicht könnte RRTI mir hier helfen?!

Ja... Einfache Antwort : Interfaces

Also ganz einfach:

Immer gegen Interfaces programmieren und "NIE" gegen Implementationen...

Dann einfach eine Factory die aus einem Interface das Object erzeugen kann und fertig...

So müssen alle Units nur gegen die Interface-Declarations-Unit und gegen die Factory linken...

Mavarik

[stahli]

Ein bestehendes, großes Projekt würde ich auch (wie ich Uwes Beitrag entnehmen würde) erst mal nur dezent umstellen.

Gibt es irgendwelche realen Probleme oder stehen gravierende Erweiterungen an, die Du mit der aktuellen Struktur nicht mehr realisieren kannst?

Die Trennung in unabhängige Bestandteilen ist sicherlich ein gutes Ziel, aber es kann sein, dass Du, nachdem Du einmal angefangen hast, aus dem Kreislauf gar nicht mehr raus kommst.

Also vielleicht wäre es auch besser, das alte Projekt so zu belassen und bei neuen Projekten auf eine klarere Struktur zu achten.

Wir haben uns z.B. entschieden, ein sehr altes Projekt lieber gleich neu aufzubauen, als an dem alten noch etwas zu verschlimmbessern.

Man muss halt Aufwand und Nutzen abwägen und die Konsequenzen bedenken.


Das würde ich auch auf Mavariks Beitrag beziehen.
Interfaces sind nützliche Konstrukte. Aber ein bestehendes großes Projekt auf Interfaces umzustellen ist u.U. schon eine gewaltige Aufgabe - zumal wenn man nichts über das derzeitige Projekt weiß.
Für neue Projekte könnte man allerdings über den Einsatz von Interfaces nachdenken.

[OlliWW]

Hallo,

Zitat von stahli:

Ein bestehendes, großes Projekt würde ich auch (wie ich Uwes Beitrag entnehmen würde) erst mal nur dezent umstellen.

Gibt es irgendwelche realen Probleme oder stehen gravierende Erweiterungen an, die Du mit der aktuellen Struktur nicht mehr realisieren kannst?

Die Trennung in unabhängige Bestandteilen ist sicherlich ein gutes Ziel, aber es kann sein, dass Du, nachdem Du einmal angefangen hast, aus dem Kreislauf gar nicht mehr raus kommst.

Also vielleicht wäre es auch besser, das alte Projekt so zu belassen und bei neuen Projekten auf eine klarere Struktur zu achten.

Wir haben uns z.B. entschieden, ein sehr altes Projekt lieber gleich neu aufzubauen, als an dem alten noch etwas zu verschlimmbessern.

Man muss halt Aufwand und Nutzen abwägen und die Konsequenzen bedenken.

Wir entwickeln nur ein Projekt, deswegen muss, wenn Änderungen vorgenommen werden, es an diesem Projekt sein. Bei 2 Mio Zeilen ist etwas zu Refaktor'n immer eine Mamutaufgabe.
Das Problem momentan ist, dass der Kompilier-Vorgang sehr lange dauert und die Intellisense der IDE gar nicht nutzbar ist. Wenn ich "." STRG + Leertaste drücke dauert es sehr lange bis die IDE sich überhaupt wieder fängt. Dass sie mir dann Vorschläge macht, habe ich schon lange aufgegeben

Mit der Brechstange habe ich mal zum Testen die Abhängigkeiten zwischen den beiden Packages aufgelöst und siehe da: Die IDE funktioniert wieder. Von daher würde ich gern diesen Weg gehen.

[himitsu]

Und noch bissl Hilfe, beim Suchen für's Auflösen.

Delphi Unit Abhängigkeiten
Delphi Unit Dependencies / Delphi Unit Dependency

http://www.delphipraxis.net/180345-u...rstellung.html
http://www.easy-ip.net/delphi-unit-d...y-scanner.html


Der Vorteil bei Packages/DLLs ist, dass nicht ständig immer wieder alles kompiliert werden muß. (auch wenn nicht immer jede Unit neu kompiliert, sondern ein vorhandenes Kompilat nur noch reingelinkt wird, auch man sagt "Build" statt "Compile")

[Uwe Raabe]

Zitat von Mavarik:

Immer gegen Interfaces programmieren und "NIE" gegen Implementationen...

Dann einfach eine Factory die aus einem Interface das Object erzeugen kann und fertig...

So müssen alle Units nur gegen die Interface-Declarations-Unit und gegen die Factory linken...

Das ist im Wesentlich auch nichts anderes als mein Vorschlag eines Prozedurtyps (Interface), Globale Prozedurvariable (Factory) und der implementierenden Prozedur (Objekt-Instanz). Nur daß in meinem Fall die Änderungen am Sourcecode nur minimal sind und trotzdem den gewünschten Effekt erzielen.

In meinem Vortrag "Altlast oder Erbschaft" auf den Delph-Tagen 2015 hatte ich diese Ansatz kurz angesprochen.

[Mavarik]

Zitat von stahli:

Wir haben uns z.B. entschieden, ein sehr altes Projekt lieber gleich neu aufzubauen, als an dem alten noch etwas zu verschlimmbessern.

Diese Diskussion kommt bei uns 1x im Quartal auf... Neu schreiben und direkt alles richtig machen oder refrakturieren.

Bei 12 Mio. Zeilen überlegt man sich ein "mal eben" neu schreiben... (In unserem Fall seit 10 Jahren).

Also immer ein Häppchen.