Uses: Interface vs. Implementation Section

**DeddyH**

Das vorrangige Ziel einer jeden Diskussion sollte der Austausch von Argumenten sein und nicht das Durchdrücken der eigenen Meinung. Gerade bei Themen wie diesem kann so eine Diskussion aber nur ergebnisoffen geführt werden (siehe Daniels Post), was wiederum voraussetzt, dass alle Teilnehmer Willens und in der Lage sind, die Argumente der anderen zu prüfen und deren Meinung zu akzeptieren. Und genau das vermisse ich in letzter Zeit leider immer häufiger in diesem Forum, so auch hier.

**himitsu**

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*

**stahli**

Zitat von himitsu:

[list][*] in welcher Reihenfolge werden Unit eingebunden[list][*] 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

Ich hatte Dir diesbezüglich schon mal irgendwann zaghaft widersprochen.
Bei meinem Test

http://www.delphipraxis.net/158879-p...ihenfolge.html konnte ich das nämlich nicht nachvollziehen.
Eigentlich war ich auch davon ausgegangen, dass man sich auf die Initialisierungsreihenfolge verlassen kann. Offenbar ist dies aber nicht so.
Jedenfalls bin ich auf das Problem gestoßen, da eine Liste in einer verwendeten Unit entgegen meiner Erwartung nicht rechtzeitig instanziiert wurde.

Aktuell habe ich jetzt das Problem nicht und auch nicht weitere Tests unternommen, aber möglicherweise hängst Du Dich doch etwas zu weit aus dem Fenster...?

**himitsu**

Ist jetzt vielleicht ein bissl extrem, das Beispiel, aber so auf die Schnelle dahingetippt:

- alle Units, bis auf Eine in der Implementation eingebunden
- nur bei einer Unit (UnitG) kann ich dir genau sagen wann diese geladen/freigegeben wird.
> ganz am Anfang und ganz zum Schluß (da Diese immer im Interface eingebunden wurde)

Die Einbindung in der DPR entspricht der Einbindung im Interface einer Unit.

Du kannst aber auch gerne die Units aus der DPR rausnehmen und in eine weitere Unit verlegen (alles in die Implementation oder alles ins Interface).
Da es mir hier nur um die Reihenfolge der eingebundenen Units ging und wie diese initialisiert werden ... ist es grundsätzlich erstmal egal, ob diese in er DPR oder in einer weiteren Unit eingebunden wurden.

Gegeben ist also

markieren

Delphi-Quellcode:

			uses UnitG, Unit1, Unit2, Unit3;

begin

  UnitG.DoLog('Main');

end.

// der Rest steht in der Demo

und nun versuch mir zu sagen in welcher Reihenfolge diese Units geladen werden.

Das kann dir keiner zu 100% beantworten, außervielleicht die, welche den Compiler/Linker erstellt haben, falls sie das überhaupt wissen.
(abgesehn derer, welche es ausprobieren, versuchen eine Regelmäßigkeit zu erkennen und dann hoffen ihr so erlangtes Teilwissen würde immer und in allen Situationen stimmen)

**implementation**

Zitat von himitsu:

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.

Full Ack! Genauso sehe ich das auch.

Und das ist der Grund weshalb ich hier eine Argumenatation mit "Clean Code" für vollkommen unangebracht halte.
Denn die Uses-Klausel wird in Interface und implementation gleichermaßen veröffentlicht.
Irgendwie nicht, aber auch irgendwie doch. Andere Units sehen die Klausel nicht, hängen aber von ihr ab. Egal ob Interface oder Implementation.

**brechi**

Zitat von implementation:

Zitat von himitsu:

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.

Full Ack! Genauso sehe ich das auch.

Und das ist der Grund weshalb ich hier eine Argumenatation mit "Clean Code" für vollkommen unangebracht halte.
Denn die Uses-Klausel wird in Interface und implementation gleichermaßen veröffentlicht.
Irgendwie nicht, aber auch irgendwie doch. Andere Units sehen die Klausel nicht, hängen aber von ihr ab. Egal ob Interface oder Implementation.

Ich stimme euch beiden da voll zu

Zitat von implementation:

Denn die Uses-Klausel wird in Interface und implementation gleichermaßen veröffentlicht.
Irgendwie nicht, aber auch irgendwie doch. Andere Units sehen die Klausel nicht, hängen aber von ihr ab. Egal ob Interface oder Implementation.

Hä? Irgendwie nicht, aber irgendwie doch? Wer sieht was nicht, hängt aber ab? Häää? Diese Aussage ist -sagen wir es vorweihnachtlich- ein wenig weißbärtig.

Der Implementierungsteil ist versteckt seine Details, der Interface-Abschnitt nicht. Per Definitionem. Klar ist da nicht wirklich was versteckt, denn ich kann ja in den Quelltext reinschauen. Aber wie die Funktionen der Unit genau umgesetzt ist und mit welch fiesen geheimen Trickunits gearbeitet wird... Also das ist.. doch ... irgendwie... wie soll ich's ausdrücken... Verborgen. Also, von der DCU her. Irgendwie schrietegal, wie der Autor das umgesetzt hat. Aber er sagt uns (über das Interface), was für andere Units wir benötigen. Klar benötigt man auch irgendwie die Units im Implementierungsabschnitt. Zum kompilieren. Logisch.

Aber da die ganze Zeit vom Quelltext die Rede ist, kann man das wohl vernachlässigen. Oder meintest Du das?

Mal was anderes:
Übrigens verdiene ich mein Geld damit, meine Units im Implementationsabschnitt anzugeben. Ob ich genauso wenig/viel Geld verdienen würde, wenn ich sie alle im Interfaceabschnitt angebe? Keine Ahnung. Ich bin doch nicht so blöd und probier das aus. Nacher bin ich arbeitslos, oder meine Tastatur explodiert oder so.

Gleiches könnte übrigens den Programmierern passieren, die vielleicht mal ausprobieren wollen, wie es sich anfühlt, wenn man eine Unit in den Implementation-Abschnitt verfrachtet.

Also Leute: Auf gar keinen Fall die andere Seite ausprobieren, oder -was noch schlimmer wäre- der anderen Seite zugestehen, das sie Recht haben könnte. Schwerer Fehler! Eingeständnis der eigenen Unzulänglichkeit.

In diesem Sinne möchte ich das Niveau nochmals verschieben:
Implementationsusesverwendungsverweigerer sind Schlaumeier! Oder waren es die Implementierungsabschnittsusesverwender, die Klugscheißer sind? Oder umgekehrt? Passt beides.

Vielleicht kommen wir so weiter.

**implementation**

Zitat von Furtbichler:

Zitat von implementation:

Denn die Uses-Klausel wird in Interface und implementation gleichermaßen veröffentlicht.
Irgendwie nicht, aber auch irgendwie doch. Andere Units sehen die Klausel nicht, hängen aber von ihr ab. Egal ob Interface oder Implementation.

Hä? Irgendwie nicht, aber irgendwie doch? Wer sieht was nicht, hängt aber ab? Häää? Diese Aussage ist -sagen wir es vorweihnachtlich- ein wenig weißbärtig.

Der Implementierungsteil ist versteckt seine Details, der Interface-Abschnitt nicht. Per Definitionem.

Es geht lediglich um die Uses-Klausel. Erkläre mir bitte mal, inwiefern der implementation-Teil die Uses-Klauseln mehr versteckt als der interface-Teil.
Egal, in welchem Teil du die Klauseln jetzt hinpackst: Alle anderen Units, die deine Unit einbinden, können die Klauseln so oder so nicht sehen. Und egal, in welchem Teil die Klausel liegt, Units die deine Unit einbinden, hängen immer von den in deiner Unit eingebundenen ab. Dependency-Tree.
Insofern gehört die Klausel eigentlich in keinen von beiden Teilen, denn das Verstecken betrifft sie überhaupt nicht.

Zitat von Furtbichler:

Also Leute: Auf gar keinen Fall die andere Seite ausprobieren, oder -was noch schlimmer wäre- der anderen Seite zugestehen, das sie Recht haben könnte. Schwerer Fehler! Eingeständnis der eigenen Unzulänglichkeit.

Schau dich mal um. Siehst du die Glaswände? Da hinten steht sogar ein Schild: "Steinekatapultieren auf eigene Gefahr"

Zitat:

Es geht lediglich um die Uses-Klausel. Erkläre mir bitte mal, inwiefern der implementation-Teil die Uses-Klauseln mehr versteckt als der interface-Teil.

Na weil die Units dort aufgelistet sind und nicht im Inteface-Abschnitt.
Folgendermaßen kann der Code gelesen werden: "Ich als Unit benutze diese Units im Implementierungsabschnitt für die Implementierung meiner nach außen hin sichtbaren Funktionalität, und um diese Funktionalität nutzen zu können, müsstest Du nur die Units in meinem Interface-Abschnitt bei dir einbinden."

Zitat:

Schau dich mal um. Siehst du die Glaswände? Da hinten steht sogar ein Schild: "Steinekatapultieren auf eigene Gefahr"

Nö. Hier nicht. Hier sind die Wände ganz weich

. Das mit den Glaswänden (cool!) muss bei Dir sein

.

Übrigens, falls es dir nicht aufgefallen ist: Ich blase ins gleiche bornierte Horn wie Du. Nur ich habe es schon bemerkt und verarsch dich mit dem letzten Absatz. Mach das mit dir selbst auch mal, zur Abwechslung. Dann wirst Du auch wieder lockerer.

**DeddyH**

Ist eigentlich schon jemandem aufgefallen, dass diese "Diskussion" zu nichts führt außer persönlichen Anfeindungen? Aber da ich sowieso die ganze Zeit geflissentlich ignoriert werde, dürfte dieser Einwand auch wieder im Sande verlaufen. Also zieht Euch meinetwegen die Boxhandschuhe an und schlagt Euch gegenseitig die Köpfe ein