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:

Zitat von Martin W (Beitrag 1141809)

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:

Zitat von himitsu (Beitrag 1141897)

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:

Zitat von himitsu (Beitrag 1141897)

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:

Zitat von himitsu (Beitrag 1141897)

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

Ach was.

Zitat:

Zitat von himitsu (Beitrag 1141897)

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:

Zitat von himitsu (Beitrag 1141897)

Bei mir alles ins interface, ausnahmslos,

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

Zitat:

Zitat von himitsu (Beitrag 1141897)

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

[himitsu]

Zitat:

Zitat von DeddyH (Beitrag 1142137)

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

Worbei Delphi ja nicht der Anfang war.
Lang lebe Turbo Delphi Pascal. :cheer:

Man könnte ja mal den Herrn Wirth fragen, was er sich dabei dachte. :gruebel:

[uligerhardt]

Zitat:

Zitat von himitsu (Beitrag 1142140)

Man könnte ja mal den Herrn Wirth fragen, was er sich dabei dachte. :gruebel:

Gar nix :mrgreen: - such mal hier nach "unit". Bzgl. seiner späteren Schöpfungen kannst du mal hier schauen. Da war das Modul-Konzept wohl etwas anders als bei Borland.

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1142136)

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

[himitsu]

Wurden in TP Units (deren Deklarationen) denn durchgereicht?

In Delphi machen die das ja nicht.

[brechi]

Packt ihr dann bei einem neuen Formular erstmal alle Units in den Implementationsteil die nicht benötigt werden? Und wenn ihr überprüfen wollt ob eine Unit schon eingebunden ist schaut ihr immer in beiden Uses Bereichen nach? Und Falls dann mal in einem Formular eine Unit im Objekt/Formular benötigt wird kopiert ihr die immer aus dem Implementationsteil in den Interfaceteil? Warum erzeugt Delphi alle benötigten Units immer im Interfacebereich? Fragen über Fragen :)
Ich mach es wie Himitsu, in den Implementationsbereich kommen nur Units mit Kreuzreferenzen. Darf aber jeder machen wie er will, denke ein "richtig" gibts nicht, es hat beides Vor- und Nachteile.

[sx2008]

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?

* 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.
Der ModelMaker Tools Unit dependency analyzer ist als Standalone Freeware-Anwendung verfügbar. Einfach mal testen...

[angos]

Zitat:

Zitat von sx2008 (Beitrag 1142116)

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ß

[Furtbichler]

Eins vorneweg: Ich verwende den Uses-Clause Manager (Shift-Alt-U) von GExperts! Damit habe ich keine Ausrede mehr, es sei zu anstrengend, die Uses-Abschnitte aufzuräumen.

Zitat:

Zitat von brechi (Beitrag 1142298)

Packt ihr dann bei einem neuen Formular erstmal alle Units in den Implementationsteil die nicht benötigt werden?

Die Units, die im Deklarationsteil des Formulars benötigt werden, packt Delphi ja schon von sich aus in den Interface-Teil. Darum muss ich mich also nicht kümmern. Der Rest kommt in den Implementation-Teil.

Zitat:

Zitat von brechi (Beitrag 1142298)

Und wenn ihr überprüfen wollt ob eine Unit schon eingebunden ist schaut ihr immer in beiden Uses Bereichen nach?

Nein, ich lass den Compiler gegen die Wand fahren und binde die fehlende Unit nach Bedarf ein.

Zitat:

Zitat von brechi (Beitrag 1142298)

Und Falls dann mal in einem Formular eine Unit im Objekt/Formular benötigt wird kopiert ihr die immer aus dem Implementationsteil in den Interfaceteil?

Dafür gibt es GExperts.

Zitat:

Zitat von brechi (Beitrag 1142298)

Warum erzeugt Delphi alle benötigten Units immer im Interfacebereich?

Na weil sie dort gebraucht werden.

Zitat:

Zitat von brechi (Beitrag 1142298)

...denke ein "richtig" gibts nicht, es hat beides Vor- und Nachteile.

Nenne mir Nachteile, wenn man seinen Code aufräumt. Wenn etwas an einer bestimmten Stelle nicht benötigt wird, dann gehört es dort nicht hin. Units, die im Interface-Abschnitt nicht referenziert werden, gehören dort hin? So so. Das muss mir einer erklären. Mit dem gleichen Argument kann ich lokale Variablen als private Felder deklarieren und private Felder gleich als public. Stört doch nicht und ist praktisch, weil, wenn man die später doch mal an anderer Stelle benötigt, hat man sie gleich. Und, ach, das ist mir zu viel Mühe, immer drauf zu achten, das jedes Objekt so nah wie möglich an seiner Verwendung deklariert ist.

Zitat:

Zitat von angos (Beitrag 1142312)

Aber es gibt auch das KISS-Prinzip.

'Simple' heißt nicht: 'An einer Stelle'. Oder deklarierst du alle Variablen auch 'an einer Stelle'. Weil, is ja 'KISS' ;-)

Zitat:

Das es ein Tool dafür gibt, ist kein Grund diese Funktionalität zu nutzen.

Aber ein Indiz dafür, das es jenseits des eigenen Horizonts noch andere Argumente gibt.

Zitat:

Fazit: Aufgrund der Lesbarkeit (alles an einer Stelle ist übersichtlicher)

Ist es nicht. Wie schon gesagt, dann gilt das auch für Variablen.

Ihr immer mit euren zirkulären Referenzen: Wenn ihr davor Angst habt, dann lernt doch einfach, eure Units so zu bauen, das das nicht passiert. Ich mach mir doch meinen Code nicht unleserlich ('alles an einer Stelle') nur weil ich keinen Plan habe, wie ich zirkuläre Referenzen vermeiden kann.

[angos]

Zitat:

Zitat von Furtbichler (Beitrag 1142313)

Zitat:

Zitat von angos (Beitrag 1142312)

Aber es gibt auch das KISS-Prinzip.

'Simple' heißt nicht: 'An einer Stelle'. Oder deklarierst du alle Variablen auch 'an einer Stelle'. Weil, is ja 'KISS' ;-)

Nein, das mache ich natürlich nicht und ich habe auch nicht behauptet, dass KISS heißt, alles an einer Stelle unterzubringen. Nur in genau diesem Fall (eingebundene Units) ist es (für mich persönlich) ganz klar übersichtlicher.

Zitat:

Zitat:

Das es ein Tool dafür gibt, ist kein Grund diese Funktionalität zu nutzen.

Aber ein Indiz dafür, das es jenseits des eigenen Horizonts noch andere Argumente gibt.

Absolut richtig. Deswegen frage ich ja nach. Bis auf den Punkt, dass es den Kompiliervorgang beschleunigen kann, sehe ich noch keinen Mehrwert für mich. Ich nehme nicht einfach Dinge als gegeben hin, nur weil xy das ja auch so macht. Wenn es für mich einen wirklichen Mehrwert bringt will ich das ja auch nutzen. Nur dafür wurde für mich noch kein Argument gebracht, denn der Kompiliervorgang ist in meinen jetzigen Projekten mehr als schnell genug. Ich will das ja nicht schlecht reden, ich möchte einfach nur Argumente, warum man das tun sollte.

Zitat:

Zitat:

Fazit: Aufgrund der Lesbarkeit (alles an einer Stelle ist übersichtlicher)

Ist es nicht. Wie schon gesagt, dann gilt das auch für Variablen.

OK, dann ist es für dich nicht lesbarer und zieht somit für dich als Argument, das zu benutzen. Für mich eben nicht, aber das ist einfach eine Sache der persönlichen Vorlieben.

Zitat:

Ihr immer mit euren zirkulären Referenzen: Wenn ihr davor Angst habt, dann lernt doch einfach, eure Units so zu bauen, das das nicht passiert. Ich mach mir doch meinen Code nicht unleserlich ('alles an einer Stelle') nur weil ich keinen Plan habe, wie ich zirkuläre Referenzen vermeiden kann.

Es wäre schön, wenn man konstruktiv bleiben könnte... Fehler können nunmal passieren, warum nicht dafür sorgen, dass sie nicht auftreten können? Man sagt ja auch keinem Menschen an einer Metalpresse, dass er lernen soll seine Finger nicht in das Gerät zu halten (zumindest heutzutage ;) ), sondern man baut die Maschinen so, dass beide Hände für das Betätigen der Presse notwendig sind.

Achja: Ich habe das auch mal so gemacht, mit dem Verteilen der Units und hatte mir irgendwann mal eine zirkuläre Referenz eingefangen.



Gruß

[himitsu]

Wenn du die Variablen ansprichts ... dann hätte ich gern eine lokale Usesklausel, denn es kommt oftmals vor, daß ich eine Unit nur innerhalb einer einer bestimmten Methode benötige.


Nja, im Prinzip ist erstmal eine Glaubensfrage, wie als ob man begin, BEGIN, Begin oder begIN schreiben möchte.



Für den Kompiler gibt es allerdings nur Nachteile, egal was man macht.

> gibt es nur die Interfaceklausel, dann hat er weniger Arbeit [edit] ups, ich meinte ja die Nachteile
> gibt es nocheine Klausel in der Implementation, dann hat er mehr Arbeit
Wobei es auch so schon nicht leicht ist, da er eigentlich versucht Units in der Reihenfolge einzubinden, wie man es dort angegeben hat, was ja leider nicht immer klappt.

Aber wenn man niemals Initializations- und Finalizations-Abschnitte verwendet, dann hab man keine Probleme zu befürchten, wenn die genutzten Units in der Implementation stehen.

[neo4a]

Vielleicht kommt ein Teil der Meinungspolemik in diesem Thread auch von der unterschiedlichen Herangehensweise bzw. Nutzung von Delphi?

Beim RAD-Ansatz übernimmt ja Delphi quasi die Verwaltung der Units und packt sie alternativlos und korrekt in den Interface-Bereich.

Sobald ich jedoch eigene Klassen oder Forms/Frames ohne RAD einsetze, bin ich allein der "Bauherr" meiner Units und der Verwalter von deren Referenzen. Und Furtbichler könnte sich z.B. auch auf N.Hodge berufen, der hier Regeln aufstellt und da besonders darauf hinweist, dass man funktionierenden Code haben kann, ohne irgendwelchen Code in der Interface Section (mittels eines DI-Frameworks).

Hier kommen dann auch schon Entwicklungs-Prinzipien und -Methoden (Law of Demeter, Testable Code, Clean Code) in's Spiel, die etwas über den bloßen Wunsch hinaus gehen, immer alles im Blick haben zu wollen.

[DeddyH]

Zitat:

Zitat von neo4a (Beitrag 1142335)

Beim RAD-Ansatz übernimmt ja Delphi quasi die Verwaltung der Units und packt sie alternativlos und korrekt in den Interface-Bereich.

Nicht immer. Wenn man auf andere Formulare zugreifen möchte, die entsprechende Unit aber noch nicht eingebunden hat, packt Delphi diese in den implementation-Abschnitt, wenn man die Nachfrage bestätigt.

[neo4a]

Zitat:

Zitat von DeddyH (Beitrag 1142337)

Zitat:

Zitat von neo4a (Beitrag 1142335)

Beim RAD-Ansatz übernimmt ja Delphi quasi die Verwaltung der Units und packt sie alternativlos und korrekt in den Interface-Bereich.

Nicht immer. Wenn man auf andere Formulare zugreifen möchte, die entsprechende Unit aber noch nicht eingebunden hat, packt Delphi diese in den implementation-Abschnitt, wenn man die Nachfrage bestätigt.

Das stimmt, aber wer macht denn freiwillig so etwas? ;)

Zitat:

Zitat von Delphi Pretty Good Practices #4 - Do Work in Classes

One way to tell you are not doing this is if you tend to do “OnClick” programming, or relying on event handlers to do the work of your application.

[brechi]

Zitat:

Zitat von Furtbichler (Beitrag 1142313)

Eins vorneweg: Ich verwende den Uses-Clause Manager (Shift-Alt-U) von GExperts! Damit habe ich keine Ausrede mehr, es sei zu anstrengend, die Uses-Abschnitte aufzuräumen.

Zitat:

Zitat von brechi (Beitrag 1142298)

Warum erzeugt Delphi alle benötigten Units immer im Interfacebereich?

Na weil sie dort gebraucht werden.

von den Units

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;

wird bei einem neuen Formular nur "Forms" im Interface Teil benötigt. Erst durch andere Komponenenten werden die anderen ggf. verwendet.

Unr nur weil einige Tools dies unterstuetzen, ist es noch lange kein Grund, dass dies "richtig" ist. Der Rest hat sich Angos schon geäußert.

[neo4a]

Zitat:

Zitat von brechi (Beitrag 1142345)

Unr nur weil einige Tools dies unterstuetzen, ist es noch lange kein Grund, dass dies "richtig" ist. Der Rest hat sich Angos schon geäußert.

Definiere "richtig" und wir kommen zu Aspekten, die inhaltlich vielleicht auch so diskutiert werden können:

Alles, was im Interface-Teil deklariert und referenziert wird, benötigt die Klasse, um mit dem Rest-Programm arbeiten zu können.

Demgegenüber wird das, was lediglich im Implementations-Teil deklariert und referenziert wird, lediglich im Innern der Klasse benötigt.

So gesehen ist die Uses-Klausel auch eine Beschreibung der Wirkzusammenhänge der Klasse und wenn auf einmal Units im Interface benötigt werden, kann das schon ein Indiz für einen Fehler in der Klassen-Architektur sein. Da hat man dann etwas nicht "richtig" gemacht.

[neo4a]

Zitat:

Zitat von Furtbichler (Beitrag 1142313)

Eins vorneweg: Ich verwende den Uses-Clause Manager (Shift-Alt-U) von GExperts!

Der Units Cleaner vom CnPack leistet mir wirklich wertvolle Hilfe. Im Anhang sind 2 Screenshots, die erst den Start-Dialog zeigen und dann den Ergebnis-Dialog, wo man anklickt, was entfernt werden kann.

Dieser Wizard ist für mich eines der wenigen Tools, die ich von CnPack in der IDE aktiviert habe.

[implementation]

Ich möchte den Punkt der Übersichtlichkeit nochmal aufgreifen.

Bisher geht ihr alle davon aus, dass ihr/eure Firma/euer Entwicklerteam die einzigen seid, die das Projekt kompilieren.
Und das beim Build sowieso alle Abhängigkeiten bereits erfüllt sind.

Aber angenommen ich entwickle Open Source und binde noch ein paar externe Units mit ein, die nicht zum Projekt gehören.

Nun möchte jemand anders den Code auch auf seinem Zielsystem kompilieren, und schaut zunächst in die Units, welche Dependencies er braucht. Dann ist es doch viel einfacher und schneller, einfach oben im interface-Abschnitt zu schauen, gerade weil diese Klausel direkt sehr weit oben im Code ist. Man bedenke, dass der interface-Abschnitt gerne mal >200 Zeilen lang werden kann, und dementsprechend die implementation-uses-Klausel irgendwo mitten im Code liegt (erstmal finden!)

Und jetzt kommt mir bitte keiner mit: "Ausprobieren und den Compiler in den Fehler laufen lassen, dann wird man schon sehen, was er nicht findet" - denn das ist jawohl die unsauberste Methode überhaupt.
Das würde dem gleichen Prinzip folgen wie:

Delphi-Quellcode:

function Nonzero(const i: integer): boolean;
var x: extended;
begin
  try
    x := 1/i;
    Result := true;
  except
    Result := false
  end
end;

Einfach drauflos ballern und vom Fehlerfall ausgehen.


P.S.: Gut, zugegeben, die Dependencies sollten eigentlich auch mit in die Dokumentation, aber hasst es nicht jeder Programmierer, Dokumentationen zu schreiben? :stupid:

[neo4a]

Zitat:

Zitat von implementation (Beitrag 1142430)

Bisher geht ihr alle davon aus, dass ihr/eure Firma/euer Entwicklerteam die einzigen seid, die das Projekt kompilieren.

Wie kommst Du denn nur darauf?

Zitat:

Zitat von implementation (Beitrag 1142430)

Dann ist es doch viel einfacher und schneller, einfach oben im interface-Abschnitt zu schauen, gerade weil diese Klausel direkt sehr weit oben im Code ist. Man bedenke, dass der interface-Abschnitt gerne mal >200 Zeilen lang werden kann, und dementsprechend die implementation-uses-Klausel irgendwo mitten im Code liegt (erstmal finden!)

Gut. Du hast also (manchmal) Schwierigkeiten, Dich in umfangreichen Code zurecht zu finden. Kann ja mal vorkommen, auch ohne Clausthaler.

Warum benutzt Du dann nicht IDE-Tools wie die Editor-Toolbar von CnPack, die Dir nicht nur per Klick die Units listet, sondern auch noch den Sprung zu den Sektionen per Maus- oder Tastatur-Klick bietet, nicht zu reden von der einfachen Navigation zu den Prozeduren?

Neben dem bereits erwähnten Unit Cleaner ebenfalls eine sinnvolle Erweiterung vom CnPack, von dem ich wirlich nur ein halbes Dutzend Funktionen aktiviert habe.

[implementation]

Zitat:

Zitat von neo4a (Beitrag 1142438)

Warum benutzt Du dann nicht IDE-Tools wie die Editor-Toolbar von CnPack, die Dir nicht nur per Klick die Units listet, sondern auch noch den Sprung zu den Sektionen per Maus- oder Tastatur-Klick bietet, nicht zu reden von der einfachen Navigation zu den Prozeduren?

Neben dem bereits erwähnten Unit Cleaner ebenfalls eine sinnvolle Erweiterung vom CnPack, von dem ich wirlich nur ein halbes Dutzend Funktionen aktiviert habe.

Solche lustigen Tools hast du als Entwickler der Software vllt., aber nicht jeder, der das Projekt nur mal eben auf seiner Zielplattform kompilieren will, und das kann man dann auch nicht erwarten.

----
Gut. Ich gebe zu, das ganze kommt in Delphi selten vor, da jeder, der nur mal eben was fremdes kompilieren will, sich erstmal teuer Delphi kaufen muss, und wenn mans dann hat, hat man ja schon gleich ne Mega-IDE. Und letztendlich ist dort die Auswahl an Zielplattformen ja doch nicht so groß, dass das Szenario überhaupt Sinn macht.

Aber ich sags mal so: Ich arbeite schon eine ganze Weile mit dem FPC, und da öffnen sich nunmal ganz neue Möglichkeiten: denn auf einmal laufen Programme auch auf SPARC, PowerPC, ARM, Alpha und Co. Und als Entwickler kann ich das nunmal schlecht für jede CPU-Typ/Betriebssystem-Kombination kompilieren. Gängige Praxis ist es im GNU/Linux-Umfeld daher sowieso längst, vieles erst auf dem Zielsystem zu kompilieren. Und genau den Fall habe ich hier betrachtet.

Angenommen ich habe ein FreeBSD auf SPARC am laufen, muss ich jegliche Fremdsoftware von andern nunmal erst selbst kompilieren. Das ist so und ergibt sich bereits aus der Natur der Tatsache, dass es überhaupt soviele verschiedene Plattformen gibt. Und als Entwickler will man dies doch möglichst einfach machen. Und solche Aktionen, wie für den Kompilierer wichtige Abschnitte quer durch den Code zu verstreuen, ohne dass sich ein nennenswerter Vorteil ergibt, sind absolut kontraproduktiv.

[neo4a]

@implementation

Es steht Dir frei, Tools als lustig zu beurteilen. Das kommt immer gut, ist lässig und zeigt nur denen, die die Tools praktisch nutzen und es somit besser wissen, dass Du davon nur wenig verstehst. Leider ist die Delphi IDE nicht von Haus aus komplett und so braucht man Erweiterungen wie GExpert, VersionInsight, CnPack, AQTime, MadExecept. Das Konzept kennt man auch aus anderen IDEs. Und nicht nur ich finde: Gutes Werkzeug ist durch nichts zu ersetzen!

Schau bitte in meinen Post 28 in diesem Thread für eine Erklärung, warum es klar ist, wann welche Sektion für eine Unit-Referenz verwendet wird. Ob Du das für Dich auch nachvollziehen kannst, spielt dabei eigentlich keine Rolle. Das Einhalten von Konventionen erschließt sich nicht jedem und so ist nicht nur in Delphi Clean Code ein ständiges Thema.

Dass Du mit FP und Linux noch etwas andere Sichtwinkel und Einsatzbereiche hast und i.d.R. ohne Delphi-IDE auskommen musst, ändert am Sinn der Konventionen eigentlich gar nichts.

[implementation]

Zitat:

Zitat von neo4a (Beitrag 1142467)

Es steht Dir frei, Tools als lustig zu beurteilen. Das kommt immer gut, ist lässig und zeigt nur denen, die die Tools praktisch nutzen und es somit besser wissen, dass Du davon nur wenig verstehst. Leider ist die Delphi IDE nicht von Haus aus komplett und so braucht man Erweiterungen wie GExpert, VersionInsight, CnPack, AQTime, MadExecept. Das Konzept kennt man auch aus anderen IDEs. Und nicht nur ich finde: Gutes Werkzeug ist durch nichts zu ersetzen!

Das "lustig" sollte die Tools auf keinen Fall abwerten. Natürlich sind sie für den Entwickler durchaus sehr praktisch.
Für den Entwickler. Aber eben nicht jeder Kompilierer, der das fremde Programm nur auf seiner eigenen Plattform zum laufen bringen will, will sich damit aufhalten, noch zig Add-Ins und Tools zu installieren.

Zitat:

Schau bitte in meinen Post 28 in diesem Thread für eine Erklärung, warum es klar ist, wann welche Sektion für eine Unit-Referenz verwendet wird. Ob Du das für Dich auch nachvollziehen kannst, spielt dabei eigentlich keine Rolle.

Genannter Post überzeugt mich nicht im geringsten. Die uses-Klausel im implementation-Bereich halte ich für überflüssig.

Zitat:

Das Einhalten von Konventionen erschließt sich nicht jedem und so ist nicht nur in Delphi Clean Code ein ständiges Thema.

Bitte, wo ist diese Konvention schriftlich festgehalten? Ich glaube mittlerweile eher, man hat diese Möglichkeit damals lediglich für Kreisreferenzen eingeführt, und versucht nachträglich, dem ganzen mehr Sinn einzuhauchen.

Und was bitte hat das mit Clean Code zu tun? Solche Abhängigkeiten beziehen sich auf das ganze Projekt! Das ganze Projekt kompiliert ohne sie nicht. Selbst wenn nur eine einzige Prozedur es benutzt, der effektive Bezug ist immer noch das volle Projekt, nicht die Codedatei und nicht der einzelne Abschnitt. Das ist auch der Grund, weshalb MS das im VS anders gelöst hat: Assemblies werden dort immer für das ganze Projekt zentral eingebunden.
In Delphi ist das anders, und die gängige Praxis mag anders sein. Aber das heißt nicht, dass sie besser, geschweige denn "cleaner" ist, nur weil sie vorgibt, sich auf einen kleineren Bereich zu beziehen (es schlussendlich aber nicht tut).

Zitat:

Dass Du mit FP und Linux noch etwas andere Sichtwinkel und Einsatzbereiche hast und i.d.R. ohne Delphi-IDE auskommen musst, ändert am Sinn der Konventionen eigentlich gar nichts.

Es geht nicht um mich als Entwickler, sondern um den Nutzer, der das ganze nachkompilieren will, um auch was davon zu haben.

[himitsu]

Ach ja, nur weil Delphi selber neuerdings Einiges in der Implementation einfügt, heißt noch lange nicht, daß sie sich dabei was gedacht haben.
Und auch zu sagen "schau mal, in dieser VCL-Unit ist das auch so" ... es sollte jeder bemerkt haben, daß die VCL an vielen Stellen nicht grade konsequent ist. :roll:

[neo4a]

Zitat:

Zitat von implementation (Beitrag 1142470)

Für den Entwickler. Aber eben nicht jeder Kompilierer

Diese Unterscheidung kenne ich im Delphi-Umfeld nicht. Im Linux-Umfeld ist es in der Tat eher die Regel. Nur warum soll ich als Entwickler auf hilfreiche Tools verzichten? Du als Kompilierer machst doch eh nur "make", sonst wärst Du ja Entwickler ;)

Zitat:

Zitat von implementation (Beitrag 1142470)

Zitat:

Schau bitte in meinen Post 28 in diesem Thread für eine Erklärung, warum es klar ist, wann welche Sektion für eine Unit-Referenz verwendet wird. Ob Du das für Dich auch nachvollziehen kannst, spielt dabei eigentlich keine Rolle.

Genannter Post überzeugt mich nicht im geringsten.

Damit kann ich leben.

Zitat:

Zitat von implementation (Beitrag 1142470)

Zitat:

Das Einhalten von Konventionen erschließt sich nicht jedem und so ist nicht nur in Delphi Clean Code ein ständiges Thema.

Bitte, wo ist diese Konvention schriftlich festgehalten?

Informiere Dich bitte selbst über Sinn und Zweck der Interface/Implemention-Sektionen.

Zitat:

Zitat von implementation (Beitrag 1142470)

Und was bitte hat das mit Clean Code zu tun? Solche Abhängigkeiten beziehen sich auf das ganze Projekt! Das ganze Projekt kompiliert ohne sie nicht.

Konventionen und auch Clean Code haben nichts damit zu tun, ob etwas kompiliert. Diesen Zusammenhang hast Du eingeführt.

[implementation]

Zitat:

Zitat von neo4a (Beitrag 1142476)

Zitat:

Zitat von implementation (Beitrag 1142470)

Für den Entwickler. Aber eben nicht jeder Kompilierer

Diese Unterscheidung kenne ich im Delphi-Umfeld nicht. Im Linux-Umfeld ist es in der Tat eher die Regel. Nur warum soll ich als Entwickler auf hilfreiche Tools verzichten? Du als Kompilierer machst doch eh nur "make", sonst wärst Du ja Entwickler ;)

Ich bin ja Entwickler - aber als rücksichtsvoller Entwickler achte ich eben darauf, dass der Kompilierer es einfach hat, und eben tatsächlich sich nicht weit einzuarbeiten braucht. Make nimmt da schon sehr viel ab. Autoconf noch mehr.
Aber ich gebe gern zu, dass der Fall im Delphi-Umfeld bisher eher weniger die Regel ist.

Ich will doch gar nicht, dass du auf deine Tools verzichtest. Ich nutze doch auch welche (auch wenn sie anders aussehen). Dagegen sage ich doch gar nichts :-D

Zitat:

Zitat:

Zitat von implementation (Beitrag 1142470)

Zitat:

Das Einhalten von Konventionen erschließt sich nicht jedem und so ist nicht nur in Delphi Clean Code ein ständiges Thema.

Bitte, wo ist diese Konvention schriftlich festgehalten?

Informiere Dich bitte selbst über Sinn und Zweck der Interface/Implemention-Sektionen.

Der Sinn dieser Trennung ist es, nur das an andere Module (Hauptprogramme, Units, Packages, Libraries) zu veröffentlichen, was auch tatsächlich veröffentlicht werden soll, und nicht jede kleine Fitzelroutine, die nur unitintern gebraucht wird.

Aber bei Dependencies geht es nicht um Veröffentlichung. Sondern um Abhängigkeiten der ganzen Datei bzw. sogar des ganzen Projekts.
Bei Uses-Klauseln in interface- und implementation-Teil sieht es in der Hinsicht aber genau gleich aus, was rechtfertigt dann die Unterscheidung?

Zitat:

Zitat:

Zitat von implementation (Beitrag 1142470)

Und was bitte hat das mit Clean Code zu tun? Solche Abhängigkeiten beziehen sich auf das ganze Projekt! Das ganze Projekt kompiliert ohne sie nicht.

Konventionen und auch Clean Code haben nichts damit zu tun, ob etwas kompiliert. Diesen Zusammenhang hast Du eingeführt.

Ich denke mit Clean Code meinen wir beide in diesem Kontext, dass man etwas nur dort deklariert, wo man es auch benötigt. Eine kleine Zählervariable deklariere ich lokal, weil der Bezug die jeweilige Routine ist.
Uses-Klauseln beziehen sich effektiv aber auf das gesamte Projekt, weil das gesamte Projekt diese Dependencies tatsächlich benötigt, auch wenn ich nur in einer oder zwei Routinen tatsächlich von den externen Klassen/Routinen Gebrauch mache,

[Furtbichler]

Zitat:

Zitat von implementation (Beitrag 1142430)

Dann ist es doch viel einfacher und schneller, einfach oben im interface-Abschnitt zu schauen

. Nee, ganz sicher nicht schneller. Den Compiler gegen die Wand fahren lassen, ist am schnellsten. Schon soo oft machen müssen. Soll ich bei einem fremden Projekt etwa erst alle Uses-Klauseln analyiseren? Ja bin ich denn bescheuert? F9 und fertig. Wenns passt, dann Ctrl+F9, bis es passt. Wobei ich mich ab -sagen wir- 5.000.000 Codezeilen umorientieren würde. Vielleicht.

Zitat:

Zitat von implementation (Beitrag 1142430)

"Ausprobieren und den Compiler in den Fehler laufen lassen, dann wird man schon sehen, was er nicht findet" - denn das ist jawohl die unsauberste Methode überhaupt.

WTF. Das Resultat ist 100% das gleiche, wenn nicht sogar optimaler, denn so habe ich garantiert keine unnütze Unit eingebunden.

Dein Vergleich mit dem Code ist zwar stark hinkend aber auch nicht blöd. Denn Exceptions sind doch der OOP, oder? :stupid:

Im Übrigen ist 'gegen die Wand fahren lassen' ein anerkanntes Preventive-Maintenance-Werkzeug und nicht so leicht zu verbessern.

Dein Argument mit den 1000 Zeilen bis zum implementation kann ich aber nachvollziehen. Wer so etwas ständig machen muss, wünscht sich, das die benötigten Units alle oben stehen. Na ja, dann soll er doch. Einfach den GExperts Uses Clause Manager starten, alle Units ins Interface verschieben, fertig.

Eins noch:
Die Units im Interface-Teil helfen, die Bedeutung der Unit im Kontext des Systems zu verstehen. Werden hier auch Units aufgelistet, die nur in der Implementierung benötigt werden, irritiert das. Was interessiert es mich, das der TCP-Wrapper mit ICS umgesetzt wurde (oder was weiss ich).

Was ist denn nun klarer?

Delphi-Quellcode:

Unit MyUnit;
Interface
uses BarDefinition;

Function AnExtremelyTrickyCalculation(SomeParameters : TBar) : Extended;

implementation
uses Wow, HardCore, DirtyStuff, EvenMoreDirtyStuff, PetersTricks, MikesHacks, DontPublishThis, VerySecret;
...

oder

Delphi-Quellcode:

Unit MyUnit;
Interface
uses BarDefinition, Wow, HardCore, DirtyStuff, EvenMoreDirtyStuff, 
  PetersTricks, MikesHacks, DontPublishThis, VerySecret;

Function AnExtremelyTrickyCalculation(SomeParameters : TBar) : Extended;

implementation
...

Also von der Seite aus betrachtet, würde ich den Autor der 2.Variante vierteilen.


So wie ich das sehe gibts hier zwei Meinungen:
Die Praktiker sagen "Alle Units nach oben, sonst kriech ich Augenkrebs"
Die Ästheten sagen "Alle Units da hin, wo sie hingehören, sonst kriech ich Augenkrebs"

Tja.

[neo4a]

Zitat:

Zitat von Furtbichler (Beitrag 1142482)

So wie ich das sehe gibts hier zwei Meinungen:
Die Praktiker sagen "Alle Units nach oben, sonst kriech ich Augenkrebs"
Die Ästheten sagen "Alle Units da hin, wo sie hingehören, sonst kriech ich Augenkrebs"

Ich bin weder kein Praktiker noch bin ich kein Ästhet, deshalb noch meine 3. Meinung:

Alle Units da hin, wo sie hingehören, weil
- es sich so gehört (Convention),
- es für mich und andere leichter zu verstehen und zu warten ist (Clean Code),
- es eine Form der Inline-Doku ist (Best Practice),
- jede Unit-Referenz im Interface-Teil genau hinterfragt gehört (Law of Demeter)

Und weil unsere Delphi-Welt so liberal ist, muss man keine der o.g. Gründe akzeptieren und es kompiliert trotzdem: Ist das nicht herrlich?!

[brechi]

Zitat:

Zitat von neo4a (Beitrag 1142485)

Zitat:

Zitat von Furtbichler (Beitrag 1142482)

So wie ich das sehe gibts hier zwei Meinungen:
Die Praktiker sagen "Alle Units nach oben, sonst kriech ich Augenkrebs"
Die Ästheten sagen "Alle Units da hin, wo sie hingehören, sonst kriech ich Augenkrebs"

Ich bin weder kein Praktiker noch bin ich kein Ästhet, deshalb noch meine 3. Meinung:

Alle Units da hin, wo sie hingehören, weil
- es sich so gehört (Convention),
- es für mich und andere leichter zu verstehen und zu warten ist (Clean Code),
- es eine Form der Inline-Doku ist (Best Practice),
- jede Unit-Referenz im Interface-Teil genau hinterfragt gehört (Law of Demeter)

Und weil unsere Delphi-Welt so liberal ist, muss man keine der o.g. Gründe akzeptieren und es kompiliert trotzdem: Ist das nicht herrlich?!

Richtig, ist deine Meinung. Mehr aber auch nicht.

"Alle Units da hin, wo sie hingehören, weil
- es für mich und andere leichter zu verstehen und zu warten ist (Clean Code)"

ich bin jetzt der "andere", für mich ist es nicht leichter zu warten, man muss erst die units suchen, wenn diese schoen sortiert und nach externen bilbiotheken getrennt oben stehen ist das fuer mich leicht zu verstehen:

Delphi-Quellcode:

  uses
    windows, classes, sysutils, // delphi
    fastreport, fastscript, fastirgendwas // fastreport: libs/fastreport/src
    teechart, teetools; // teechart: libs/teechart/src

Einfach zum Einbinden in andere Projekte. Da muss ich nicht immer den Compiler gegen die Wand fahren lassen.