![]() |
Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
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? |
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
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. |
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
Zitat:
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. |
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
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?
|
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
Zitat:
|
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
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. |
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
Zitat:
![]() Als mach es nicht! |
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
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. |
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
Zitat:
|
AW: Grundsatz Frage: Units sauber halten oder mit uses vollstopfen?
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:09 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz