![]() |
globale Unit mit Konstanten o.ä. sinnvoll?
Hallo,
ich hab vor kurzem mal mit einer Unit (von den Jedis?) gearbeitet, wo im Prinzip die TAPI gekapselt und u.a. jede Menge Konstanten definiert wurden. Die hab ich in mehreren Units in der Uses-Klausel eingebunden, in denen ich die TAPI eigentlich nicht gebraucht habe, aber die Konstanten. Nun habe ich wieder ein Projekt, wo viele konstante Steuerparameter an mehreren Stellen gebraucht werden. Ich hatte nun die Idee eine Unit nur für diese Konstanten zu mißbrauchen und die überall zu referenzieren. Sollte sich somit an den Konstanten mal was ändern, brauch ich das nur an einer Stelle zu tun. (Wobei sich eigentl. nichts ändern sollte, sonst würde es keinen Sinn machen das hard zu coden, aber alleine schon während der Entwicklung scheint es mir sinnvoll, wo nach und nach Konstanten dazukommen und die dann nicht in mehreren Units neu erstellt werden müssen). Kann man das somit sinnvoller Weise so machen oder gibt es da andere BestPractices? Kann man in dieser Unit auch allgemeine Hilfsfunktionen, die in dem Projekt öfter mal gebraucht werden, ablegen (ähnl. wie z.B. die Funktionen in der Unit Math)? |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Zum Thema globale Unit für Konstanten ... siehe Units SysConst und RTLConsts ... also warum nicht :roll:
Wobei es in D6 wohl noch nicht geht, aber ich kapsle immer öfters Konstanten direkt in die Klassen, zu denen sie gehören.
Delphi-Quellcode:
So hat man alles schön zusammen. :D
type
TMyClass = class private type TMySubType = Integer; ... public type TMyOtherSubType = Cardinal; ... protected const cEineKonstante = 129; ... public const cAndereKonstante = 'abx'; ... private class var FLock: TCriticalSection; ... private FField: Integer; ... protected ... public ... published ... end; Und aufgerufen wird's z.B. so TMyClass.cEineKonstante. |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Es ist sinnvoller etwas was konstant ist nur an einer stelle zu definieren.
Einige probleme bei C/C++ rühren z.B. daher das viele Biliotheken (früher mal?) ihre eigene TRUE und FALSE-Konstanten entsprechend (unterschiedlich) definieren |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Eigentlich ist das nicht schön. Insbesondere ist das nicht OOP. Die OO sagt: "gruppiere nach Semantik, nicht nach Syntax", d.h. Konstanten zum Thema XY sollten in ne Unit XY (zusammen mit Funktionen, Klassen, etc. zum gleichen Thema) und nicht mit Konstanten zum Thema Z vermischt werden.
Leider sind solche Units eine weit verbreitete Unsitte. Der Grund warum, das Gruppieren nach Syntax schlecht ist ist folgender: Wenn du irgendwas aus der Unit wiederverwenden willst, musst du entweder die benötigten Teile "rausoperieren" (was fehleranfällig und lästig ist) oder du musst ungenutzte Konstanten mitschleppen, was der Übersichtlichkeit abträglich ist. Außerdem erzeugst du eine unnötige Kopplung an die Datei. Siehe mein Vortrag von den letzten Delphi-Tagen: ![]() mfg Christian |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Entschuldige Christian,
aber nichts anderes habe ich aus den vorhergehenden Beiträgen entnommen. Konstanten (und/oder ..), die zu einem Thema gehören, werden in einer (Themen-Zentral-Unit) zusammengefasst. Gruß K-H |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Zitat:
|
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Zitat:
Ich sehe also nicht, wo wir uns widersprechen. mfg Christian |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Zitat:
Hätte ich alles in einer Unit wäre mein einfaches Support-Tool mehrere MB größer und würde einige andere DLL's zur laufzeit benötigen da diese (für diese Anwendungszweck) unnötigen Abhängigkeiten in die Exe kompiliert werden. |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Wenn die Klassen nicht verwendet werden, dann wird ihr Code auch nicht in die EXE/DLL/BPL einkompiliert.
Es macht diesbezüglich also keinen Unterschied, ob die Klassen in der Unit liegen oder nicht. OK, man sollte nicht, so wie in SysUtils oder Classes alles in Initialization initialisieren, denn dann wird es dennoch eingebunden, da es ja in Initialization verwendet wird. :roll: Dafür gibt es seit einer Weile das
Delphi-Quellcode:
, welches nur eingebunden und wie das Initialization aufgerufen wird, wenn die Klasse wirklich verwendet wurde.
class constructor Create;
|
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Zitat:
Zitat:
|
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Ich glaube wir haben hier eine Form von
![]() Es gibt dabei einen Graubereich, in dem man abwägen kann, ob man jetzt in nem bestimmten Fall das besser trennt oder zusammen lässt. Was jetzt wie mit einkompiliert wird (himitsu hat da nen wichtigen Punkt erwähnt) kann bei der Überlegung ne Rolle spielen. Auf der anderen Seite spielen auch Lesbarkeit und Übersicht ne Rolle (zu lange Units sind unübersichtlich, zu viele Units sind unübersichtlich, zu viel Code, der nicht verwendet wird ist unübersichtlich). Man muss eben nen Mittelweg finden. Also ich sage nicht, dass man auf Teufel komm raus Konstanten und Klassen zusammen lassen soll und du hast auch nie gemeint, dass man Konstanten immer in ne eigene Unit packt, egal obs Sinn macht oder nicht. Essentiell vertreten wir die selbe Position. ==> ViolentAgreement. Wir sollten uns nicht drüber streiten. ;-) mfg Christian |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Zitat:
Du hast es gut ausgedrückt. |
AW: globale Unit mit Konstanten o.ä. sinnvoll?
Ich glaub das hast du nicht ganz richtig verstanden.
Die Klassenkonstruktoren werden automatisch aufgerufen, aber im Gegensatz zum Initialization-Abschnitt wird die Klasse nur eingebunden wenn sie verwendet wird und ihre Initialization (class constructor) wird nur aufgerufen, wenn die Klasse eingebunden wurde. Macht man das in dem Initialization-Abschnitt, dann wird schon alleine durch die Initialization die Klasse eingebunden, egal ob sie wo anders noch verwendet wird. Leider gibt es sowas nicht für die Resourcen
Delphi-Quellcode:
, welche immer gelinkt werden, egal ob sie nötig sind. :cry:
{$R ...}
Wäre schön, wenn man diese auch irgendwo dranbinden könnte. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:24 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