Hier kann es auch kein 100% Richtig oder Falsch geben.
Zitat:
Die Ästheten sagen "Alle Units da hin, wo sie hingehören, ..."
Und wer sagt wo sie hingehören?
Die Uses-Klausel hat nunmal eigentlich absolut nichts mit Interface oder Implementation zu tun.
Gäbe es keine Kreuzreferenzen, würde also ein einziger Uses-Abschnitt vollkommen reichen ... z.B. zwischen "
UNIT xyt;" und "INTERFACE" und schon gäbe es kein Problem mehr.
Vorschlag zur Versöhnung: Wir machen keine Kreuzreferenzen mehr und lassen das USES entsprechend von Emba verschieben.
Mit Implementation oder Interface kann mal also nur steuern "wann" etwas geladen wird und das ist
IMHO "nur" für Kreuzreferenzen wichtig.
Denn im Interface angegeben, werden sie nicht "veröffentlicht".
> es ist in einer anderen
Unit nicht erkennbar welche Units die eingebundenen Units wiederum einbinden, noch werden irgendwelche Typen, Funktionen, Variablen oder Konstanten einer eingebuntenen
Unit nach außen veröffentlicht/durchgereicht, egal ob diese in der Implementation oder im Interface eingebunden wurde.
Die einzigen Wirkungen sind, worauf der Unterschied "Implementation" oder "Interface" Einfluß besitzt:
- in welcher Reihenfolge werden Unit eingebunden
- im Interface eingebundene Units werden immer vor der Unit geladen, welche sie eingebunden hat
deren Register-Prozedur und der Initialization-Abschnitt werden also immer ausgeführt, bevor die eigene Unit geladen wird
- in der Implementation eingebundene Unit "können" auch erst später geladen/initialisiert werden, also auch erst nachdem irgendein Code der ladenden Unit ausgeführt würde
- beim Entladen ist die Reihenfolge natürlich andersrum
- außer daß man in der Implementation natürlich nur auf Dinge von Units zugreifen kann, welche auch "vorher" deklariert wurden (mehrere USES, im selben Bereich, sind ja nicht möglich, so wie bei TYPE, VAR und CONST), hat dieses nach Außen keine Wirkung ... nix vonwegen "veröffentlichen" des Interface-Zeugs oder so
- "ich" habe gerne (viele) zusammengehörrige Units auch zusammenhängend eingebunden (kleine Grüppchen)
würde ich da jetzt diese auch noch auf Implementration/Interface aufteilen, wären meine Gruppen "kaputt"
Was nun der/die Einzelne daraus für Schlüsse zieht und wie er/sie das letztendlich verwendet, ist jedem selber überlassen.
Clean Code hin oder her, jede(r) kann machen was er/sie will und wie er/sie es mag.
Für mich ist letztendlich das Fehlerpotential ausschlaggebend und für mich zählen unnötige und fahrlässig platzierte globale Variablen genuso dazu, wie Implementationsunits (Ladereihenfolge).
Zu Clean Code:
- ja, es hat hier und da gute Ansätze, aber es ist keine "Vorschrifft" und ist auch nicht immer der Weißheit letzer Schluß
- die einzigen wirklichen Vorschriften sind die Syntaxvorgaben
*hau*, isch habe gesprochen
*friedenspfeife rauch*
*hust* *röchel*