Uses: Interface vs. Implementation Section

[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 von brechi:

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 von brechi:

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 von brechi:

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 von brechi:

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

Na weil sie dort gebraucht werden.

Zitat von brechi:

...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 von angos:

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 von Furtbichler:

Zitat von angos:

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 von neo4a:

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 von DeddyH:

Zitat von neo4a:

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 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 von 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 von brechi:

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 von brechi:

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 von Furtbichler:

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?