Uses: Interface vs. Implementation Section

[Martin W]

Hallo,


ich kann eine Unit sowohl im Interface als auch im Implementation Bereich unterbringen:

Delphi-Quellcode:

unit Test;

interface

uses
  BeispielUnit;

implementation

uses
  BeispielUnit;

end.

Ich meine bereits häufiger gelesen zu haben, dass nur die Units in den Interface Bereich sollen, die es mindestens müssen.

Welche Auswirkungen hat dies? Hat dies Auswirkungen auf z.B. Performance oder Ressourcennutzung?


Danke,
Martin W.

[implementation]

Wirklich nützlich wird diese Trennung erst bei zirkulären Unitreferenzen:

Delphi-Quellcode:

unit UnitA;

interface

uses UnitB;

implementation

end.
//------------------------
unit UnitB;

interface

uses UnitA;

implementation

end.

--> Gibt einen Fehler!

Indem wir die Klausel in der einen Unit in die nächste verschieben, können wir das umgehen:

Delphi-Quellcode:

unit UnitA;

interface

uses UnitB;

implementation

end.
//------------------------
unit UnitB;

interface

implementation

uses UnitA;

end.

Das ist meines Erachtens der einzige sinnvolle Grund, die Klausel im implementation-Teil zu nutzen.
Ansonsten finde ich es schöner, alles zentral im interface-Teil zu haben, weil dann jeder Leser sofort sehen kann, welche Abängigkeiten die Unit hat.
Dies ist aber Geschmackssache.

Einen Performance- oder Resourcenunterschied kann ich mir nicht vorstellen.

[Bernhard Geyer]

Wir haben möglichst alle Einträge im Interface-Bereich.
Dann merken wir sehr schnell wenn einer nicht aufgepasst hat und uns eine zirkulären Unitreferenzen eingebrockt hat.

[himitsu]

Jupp, möglichst immer in das Interface.

- da merkt man, wie schon erwähnt, ob man sich irgendwo Kreisbeziehungen eingehandelt hat.

- und die dort angegebenen Units sind "immer" schon initialisiert, bevor irgendein Code der eigenen Unit ausgeführt wird, bzw. externe Units werden nicht schon freigegeben, bevor nicht der letzte Code fertig ist. (bei Letzterem abgesehn von unglücklich gesteuerten Threads)



Ist eine Unit in der Implementation angegeben, dann kann es sein, daß deren Initializations-Abschnitt noch garnicht abgearbeitet wurde und man schon auf etwas noch nicht Existierendes zugreifen will.
Genauso andersrum beim beenden des Programms, bzw. beim Entladen der DLL/BPL ... dort kann dann schon wasweg sein, obwohl man es noch braucht.

[Martin W]

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

Hier steht es anders herum, leider auch ohne Begründung: http://www.delphi-treff.de/object-pa...maufbau/#c4934

[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.