Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?

[Glados]

Ich stelle mir gerade eine grundsätzliche Frage.

Ich räume seit mehreren Monaten ein größeres Projekt auf und lagere wild rumliegenden Code in Units aus.
Units habe ich mittlerweile einige. Ein paar projektgebundene, ein Paar die man auch woanders nutzen könnte.

Daher die Grundsatzfrage: sollte man Units sauber halten und keinerlei andere Units einbinden oder ist das egal?

Beispiel: ich habe eine Unit Utils.Files.pas und eine andere namens Utils.FileCompare.pas
In Utils.Files.pas ist eine Funktion GetFileSize. Selbe Funktion brauche ich in Utils.FileCompare. Statt aber Utils.Files.pas in die uses von Utils.FileCompare.pas aufzunehmen, habe
ich GetFileSize einfach kopiert und eingefügt. Meine uses-Klausel ist somit leer.

Wie macht ihr das?

[nahpets]

Formuliere es mal etwas flapsig und provokant:

Uses ist dazu da, dass man es benutzt.

Der Sinn von Units ist es doch, Quelltext einmalig zu schreiben und mehrfach zu nutzen.

Wenn Du den Quelltext kopierst, muss Du Dir auch merken, wo Du so Deine Kopieen hingepackt hast, denn wenn mal ein Fehler auftaucht oder eine Ergänzung erforderlich ist, musst Du auch entsprechend oft korrigieren bzw. ergänzen.

[scrat1979]

Zitat von nahpets:

Formuliere es mal etwas flapsig und provokant:

Uses ist dazu da, dass man es benutzt.

Der Sinn von Units ist es doch, Quelltext einmalig zu schreiben und mehrfach zu nutzen.

Wenn Du den Quelltext kopierst, muss Du Dir auch merken, wo Du so Deine Kopieen hingepackt hast, denn wenn mal ein Fehler auftaucht oder eine Ergänzung erforderlich ist, musst Du auch entsprechend oft korrigieren bzw. ergänzen.

Sehe ich genau so. Ich bevorzuge auch die „Unit-Version“. Eine Änderung ist dann nur an einer Stelle im Code notwendig. Eigentlich ja auch der Sinn der units

Gegebenenfalls mache ich mir für verschiedene Projekte jeweils eine „unit“ welche alle benötigten anderen Units referenziert. Damit spare ich mir viele units im Hauptprogramm.

[Glados]

Nur wie handhabt man das dann, wenn man eine Unit in einem anderen Projekt braucht, die wieder zwei oder drei andere referenziert die man ggf. nicht benötigt?

[Zacherl]

Zitat von Glados:

Nur wie handhabt man das dann, wenn man eine Unit in einem anderen Projekt braucht, die wieder zwei oder drei andere referenziert die man ggf. nicht benötigt?

Ist im Grunde nicht allzu tragisch. Kann zwar deine Dateigröße dank RTTI ein wenig vergrößern, aber nicht verwendeter Code wird selbst vom Delphi-Linker in der Regel nicht mit in das Kompilat aufgenommen.

[nahpets]

Eine Unit enthält in einem Uses nur das, was sie benötigt.

Sie kann von daher nichts benötigen, das im einbindenden Projekt nicht benötigt wird.

Die Frage ist also:

Muss man Units zwingend so bauen, dass man dann, wenn man sie in ein Projekt einbindet auch alles, was sie enthält benützt.

Nein muss man nicht.

Der Linker ist (soweit ich weiß) schlau genug, nur das in das entgültige Programm zu übernehmen, was tatsächlich benötigt wird.

Man muss also keine Angst haben, durch die Nutzung großer Units, die wiederum viele weitere Units nutzen, ein Programm endlos aufzublähen.

Im Programm ist letztlich nur das tatsächlich genutzte.

Units halt nach fachlichen (oder sonstigen eigenen, der Übersicht dienlichen) Kriterien erstellen und benützen.

Wenn man immer sicherstellen will, dass eine Unit nichts enthält, was man im Programm nicht benötigt, müsste man (vermutlich) pro Funktion, pro Prozedur, pro Klasse immer eine Unit erstellen.

Das erscheint mir nicht im Sinne des Erfinders zu sein.

Erstell' doch mal ein Programm mit MAP-Datei (ist letztlich nur Text). Und dann schau da mal rein, was dort aufgeführt wird. Das ist letztlich alles, was im Programm genutzt wird.
Prüf' dann mal für das Programm, ob aus allen direkt oder indirekt per Uses eingebundenen Units alles in der MAP-Datei zu finden ist oder nur das, was Deiner Meinung nach genutzt werden müsste.

[Bernhard Geyer]

Zitat von Glados:

..., habe ich GetFileSize einfach kopiert ...

Dieses Vorgehen ist als Copy&Paste-Antipattern bekannt.
Als mach es nicht!

[Neumann]

Hallo Bernhard, den verlinkten Artikel sollte jeder mal lesen, der sich mit Programmieren beschäftigt.
Es gibt auch einige Bücher, die die Sache vertiefen; aber hier hat man eine gute Zusammenfassung und kommt schnell drauf was man selber für Probleme hat oder produziert.

[Bernhard Geyer]

Zitat von Neumann:

Hallo Bernhard, den verlinkten Artikel sollte jeder mal lesen, der sich mit Programmieren beschäftigt.
Es gibt auch einige Bücher, die die Sache vertiefen; aber hier hat man eine gute Zusammenfassung und kommt schnell drauf was man selber für Probleme hat oder produziert.

Ich finde das man die Anti-Pattern bald noch früher kennen sollte als Pattern. Sie sind oft auch viel Anschaulicher zu vermitteln als manche Pattern bei denen sich der Nutzen manchmal nicht sofort erschließt.

[Glados]

Zitat:

Dieses Vorgehen ist als Copy&Paste-Antipattern bekannt.
Als mach es nicht!

Das heißt man sollte in die uses von Unit1 dann doch besser Unit2 aufnehmen, auch wenn man Unit2.FunktionA in Unit1 nur ein- oder zweimal benötigt statt Copy&Paste?