Uses: Interface vs. Implementation Section

[sx2008]

Zitat von Martin W:

Auswirkungen auf den Performanceverbrauch / die Ressourcennutzung hat es nicht, wenn ich alles in den Interfacebereich lege?

Der Compiler hat weniger Arbeit wenn man Units wann immer möglich im Implementation-Abschnitt importiert.

[Furtbichler]

Also ich packe nur die Units, die im Interfaceteil benötigt werden, auch in den Interface-Teil. Damit dokumentiere ich die Beziehungen zwischen den Subsystemen meiner Anwendung.

Units, die für die Coderstellung benötigt werden, kommen selbstverständlich in den Implementationsteil. Dazu ist er schließlich da. Im allgemeinen finden sich hier prozedurale Toolsammlungen (xxxUtils ö.ä.)

Zirkuläre Beziehungen sind grundsätzlich zu vermeiden, sodaß ich nur selten in die Verlegenheit kommen. Und wenn, löse ich sie auf. Denn das geht ja man gar nicht: Schlamperei im Code...

[himitsu]

PS: Units, welche im Interface bennötigt werden, werden auch in der Implementation benötigt.

Zitat:

Zirkuläre Beziehungen sind grundsätzlich zu vermeiden, sodaß ich nur selten in die Verlegenheit kommen. Und wenn, löse ich sie auf

In wie kennzeichnest du Diese?

Bei mir alles ins interface, ausnahmslos, und auch oftmals möglichst in der Reihenfolge wie diese Units untereinader in Beziehung stehen.
- ist für den Compiler einfacher
- und alles was in der Implementation berbleibt, sind die "bösen Kreisreferenzen".

Wenn ich eine Unit vernändere, dann müßte ich ja ständig aufpassen, die UUnits hoch/runtezuverschieben, um dein System konsequent einzuhalten.
Und wenn ich wissen will, was für Units oder ob eine Unit verwendet wird, dann muß ich immer 2 Listen durchschauen. (Kreuzreferenzen sind selten und somit brauch ich "nie" unten nachsehn)


Das Interface stellt für mich einfach die öffentlichen Schnittstellen und die globalen Beziehungen dar. Und Unitbeziehungen gelten dabei als Globak. (Kreuzreferenzen sind eine böse Ausnahme)

[Uwe Raabe]

Zitat von himitsu:

Zitat:

Zirkuläre Beziehungen sind grundsätzlich zu vermeiden, sodaß ich nur selten in die Verlegenheit kommen. Und wenn, löse ich sie auf

In wie kennzeichnest du Diese?

Wie schon gesagt: zirkuläre Unit-Referenzen werden aufgelöst - damit sind sie so etwas wie halbfertiger Code.

Zitat von himitsu:

Wenn ich eine Unit vernändere, dann müßte ich ja ständig aufpassen, die UUnits hoch/runtezuverschieben, um dein System konsequent einzuhalten.

Aus diesem Grund gehört zu den automatischen Checks im Continuous Build auch die Überprüfung auf zirkuläre Unit-Verweise (die bei mir nur für 3rd-Party-Libs erlaubt sind) und eine Analyse, welche Unit-Referenzen überflüssig sind bzw. besser im Implementation-Teil untergebracht sind.

Sollte dann mal eine Unit aus dem Implementation-Teil in den Interface-Teil verschoben werden müssen, erledigt das der ModelMaker Code Explorer freundlicherweise von selbst.

Wie mein Vater immer sagt: Gutes Werkzeug ist durch nichts zu ersetzen.

Allerdings sei jedem sein eigener Programmierstil gegönnt. Wichtig ist nur, daß er konsistent ist.

[Furtbichler]

Zitat von himitsu:

PS: Units, welche im Interface bennötigt werden, werden auch in der Implementation benötigt.

Ach was.

Zitat von himitsu:

Zitat:

Zirkuläre Beziehungen sind grundsätzlich zu vermeiden, sodaß ich nur selten in die Verlegenheit kommen. Und wenn, löse ich sie auf

In wie kennzeichnest du Diese?

Ich kennzeichne sie nicht, ich vermeide sie.

Zitat von himitsu:

Bei mir alles ins interface, ausnahmslos,

Wieso nutzt Du nicht die Möglichkeiten von Delphi aus?

Zitat von himitsu:

- ist für den Compiler einfacher

also bei mir hat er sich noch nicht beschwert.
Ich programmiere seit 30 Jahren so und meine Erfahrungen sind gänzlich andere. Aber wie Uwe Raabe schon erwähnte: Jeder soll so schreiben, wie er es für richtig hält.

[sx2008]

Anscheinend gibt es hier zwei entgegengesetzte Meinungen, ich bin gleicher Meinung wie "Furtbichler".
Wenn es richtig wäre alle Units im Interface-Abschnitt einzubinden warum besteht dann überhaupt die Möglichkeit die Uses-Klausel im Implementation-Abschnitt zu benützen?

Ich glaube ja nicht, dass die Entwickler von Delphi unnötige Sprachfeatures erfunden haben sondern dass "himitsu" hier falsch liegt.

Hauptargument:
* wenn man eine Unit im Implementation-Abschnitt einbindet hilft dies dem Compiler weil er bei Änderung der Unit weniger kompilieren muss und interne Symboltabellen kleiner werden
Bei grossen Projekten mit Hunderten von Units kann das einen grossen Unterschied ausmachen,
denn wenn jede Unit direkt oder indirekt die Symboltabelle jeder anderen Unit benötigt dann ist das ein quadratischer Zusammenhang.

Nebenargumente:
* Es gibt in der objekt-orientierten-Programmierung das Prinzip des Information hiding.
Verberge soviel wie möglich von der inneren Struktur.
Mache alles privat mit Ausnahme der Dinge die öffentlich sein müssen.
Das kann man so auch auf die Sichtbarkeitmachung der Abhängigkeiten der verschiedenen Units anwenden

* Es gibt z.B. das Freeware Tool Icarus.
Es zeigt nach einer Analyse des Sourcecodes nicht nur unbenützte Units an, sondern zeigt auch die Units, die man vom Interface- in den Implemenation-Abschnitt verschieben kann.
Die Programmierer von Icarus haben sich bestimmt sehr gründlich mit dem Unitkonzept von Delphi auseinandergesetzt und bieten hier bestimmt keine sinnlose Funktion an.

[himitsu]

Vielleicht gab es ja anfangs nur die obere Uses-Klausel?

Die Andere wurde später eingebaut, als man merkte, daß es sonst, bei Kreuzreferenzen, unüberwindbare Hindernisse bibt.


Ich hab einfach die Erfahrung gemacht, daß man sich mit "unnötigen" Units, in der Implementation, einige nette und vorallem nicht leicht nachvollziehbare Initialisierungsreihenfolgeprobleme einfangen kann, welches es nicht gäbe, wenn Diese alle im Interface lägen.

[DeddyH]

IIRC gab es die "implementation"-uses-Klausel schon unter Delphi 1.

[p80286]

Zitat von himitsu:

Vielleicht gab es ja anfangs nur die obere Uses-Klausel?

Definiere Anfang!

Ich hatte es mir zu TP Zeiten angewöhnt alles ins die Implementation zu packen, da damit ein verstecktes "Durchreichen" von Units vermieden wurde.
In jeder Unit standen also alle benützten Units.
(Ausnahme: im Interface genutzte Units)

Gruß
K-H

[angos]

Zitat von sx2008:

Hauptargument:
* wenn man eine Unit im Implementation-Abschnitt einbindet hilft dies dem Compiler weil er bei Änderung der Unit weniger kompilieren muss und interne Symboltabellen kleiner werden
Bei grossen Projekten mit Hunderten von Units kann das einen grossen Unterschied ausmachen,
denn wenn jede Unit direkt oder indirekt die Symboltabelle jeder anderen Unit benötigt dann ist das ein quadratischer Zusammenhang.

Ok, wenn sich dass tark auf die Geschwindigkeit beim Kompilieren auswirkt, ist das natürlich ein Argument. Das konnte ich bis jetzt noch nicht feststellen, habe allerdings die Software auch auf verschiedene Exen/DLLs verteilt. Der Kompiliervorgang liegt immer unter 5 Sekunden.

Zitat:

Nebenargumente:
* Es gibt in der objekt-orientierten-Programmierung das Prinzip des Information hiding.
Verberge soviel wie möglich von der inneren Struktur.
Mache alles privat mit Ausnahme der Dinge die öffentlich sein müssen.
Das kann man so auch auf die Sichtbarkeitmachung der Abhängigkeiten der verschiedenen Units anwenden

Ja kann man so sehen. Aber es gibt auch das KISS-Prinzip. Ich habe aus diesem Grund die Information lieber an einer Stelle.

Zitat:

* Es gibt z.B. das Freeware Tool Icarus.
Es zeigt nach einer Analyse des Sourcecodes nicht nur unbenützte Units an, sondern zeigt auch die Units, die man vom Interface- in den Implemenation-Abschnitt verschieben kann.
Die Programmierer von Icarus haben sich bestimmt sehr gründlich mit dem Unitkonzept von Delphi auseinandergesetzt und bieten hier bestimmt keine sinnlose Funktion an.

Das es ein Tool dafür gibt, ist kein Grund diese Funktionalität zu nutzen. Durch das Tool habe ich nichts gewonnen. Nur weil jemand etwas tut, muss das nicht richtig sein

Zitat:

Hier sind noch zwei Argumente:
* schaut doch einfach mal nach wie das Uses Thema im Sourcecode der VCL gehandhabt wird.
Sind dort alle benötgten Unit immer im Interface-Abschnitt eingebunden?
Nein? Woran könnte das liegen?

Siehe oben.

Zitat:

* Man schaue sich mal diese Seite von ModelMakerTools an.
Man sieht, dass es direkte und indirekt benützte Units gibt.
Wenn man Units im Interface-Abschnitt einbindet, dann wird die Abhängigkeit weitergegeben, was man nach Möglichkeit vermeiden sollte.

Magst du den dadurch entstehenden Nachteil einmal erläutern?


Und zu vorherigen Posts: Wie schon gesagt wurde, zirkuläre Referenzen als Grund zu nennen, ist ein Kontra-punkt.

Fazit: Aufgrund der Lesbarkeit (alles an einer Stelle ist übersichtlicher) und um gar nicht erst durch einen Fauxpas zirkuläre Referenzen zu implementieren, die ich nachher wieder korrigieren muss, würde ich auch zukünftig weiter alles im interface deklarieren.


Gruß