Zitat von
mashutu:
Nein so etwas will ich nicht vermeiden. Aber ich will vermeiden, dass
Unit A
unit B benutzt UND umgekehrt, weil man es sonst wesentlich schwerer hat modulare Tests zu machen. Solche Zirkelbezuege sind (
IMHO) ueberfluessig und weisen auf Designfehler im Code hin, die ich rechtzeitig erkennen will.
Derartige Bezüge sind bei einem wirklich sauberen Code-Design (= 1 Klasse -> 1
Unit) sogar zum Teil absolut notwendig.
Ausserdem gibt es nur einen einzigen Grund, warum der Delphi-Compiler in diesem Moment meckert: Delphi ist ein Single-Pass Compiler und würde sonst in eine Endlosschleife rennen. Wäre es ein Multipass-Compiler, dann würde er sich gar nicht erst an der ersten
Unit-Liste aufhalten, sondern gleich den Interface-Teil parsen, und erst wenn er einen unbekannten Typen entdeckt die vorher angegebenen Units danach durchsuchen.
Wenn die andere
Unit hingegen im implementation-Teil steht, dann hat er bereits alle notwendigen Typen der Klassendeklaration geparst und kann gefahrlos weiterarbeiten.
Solche Referenzen sind in der sauberen, strukturierten Programmierung üblich, ein wichtiges Hilfsmittel und lassen sich auch ohne Probleme automatisiert testen.
Du würdest (bei einem sauberen Code-Design (nochmal: genau eine Klasse gehört in genau eine
Unit) damit sämtliche Forward-Declarations verbieten. Andersrum: Wenn Du nach genau dieser Regel konsequent arbeiten würdest, hättest Du in Deinen Units keine Forward-Declarations mehr. Entferne mal alle und gucke, ob es sich dann noch kompilieren lässt.
Dein Kollege hat im übrigen vollkommen recht: Die Uses-Listen sollten immer optimiert sein, keine unnötigen Units enthalten und wenn eine
Unit nur in der Implementierung benötigt wird, dann ist es sauber, sie auch nur dort einzubinden wo sie benötigt wird. Andernfalls könnte es nämlich insbesondere hier bei Delphi sogar passieren, dass unter Umständen eine initialization-Teil einer
Unit zu früh durchlaufen wird, weil sie oben im Interface stand anstelle im Implementation. Mal von der Compilergeschwindigkeit (und insbesondere dem Speicherverbrauch beim Kompilieren und Linken) abgesehen.
Das Hilfsmittel, um die Uses-Klauseln korrekt zu sortieren und in Deinem Fall hoffentlich schnellstmöglich das unnötige Zeug raus- und das falsch Platzierte in den implementation-Teil zu verschieben heisst Icarus Uses List Analyzer, was nicht umsonst sagt, welche Uses entfernt und verschoben gehören-