![]() |
Design: globale Variable vs globale statische Klasse
'n Abend Herrschaften!
Ich habe hier mal ein konzeptionalles Problem und hoffe mal dass ihr den einen oder anderen Kommentar dazu geben könnt oder vielleicht auch darüber berichtet, wie ihr mit folgendem Problem umgeht. Ich habe eine Applikation bei der verschiedene Units auf eine handvoll globaler Variablen zugreifen müssen. Dazu habe ich in meiner Main_Form globale Variablendeklariert (ein zentrales XML-Document, ein zentrales Grafik-Objekt, und ein paar Integer Variablen). Damit die verschiednen Units darauf zugreifen können, habe ich dann also jeweils ein "Uses Main_Form" im Implementation-Teil der Units stehen. Nachdem nun alles funktionert, stelle ich fest, dass mir dieses Vorgehen nicht so richtig gefällt: 1. Alles Units haben ein "Uses Main_Form" 2. Verwendung von globalen Variablen Um diese Unschönheiten zu beheben, dachte ich wäre es doch schön, ein "statisches" Objekt zu haben, welches die überall gebrauchten Variablen in sich birgt. Dieser "Data_Provider" hätte den Vorteil: 1. Weil statisch: nur eine Instanz. Niemand kann einfach ein zweites Data_Provider-Objekt instanziierten 2. Weil so ein statisches Objekt ja nicht Created werden braucht, kann man einfach mit TData_Provider.XML-File etc. elegant darauf zugreifen. Dazu müße ich einfach mit einem Uses im Interface jeder Unit die Data_Provider Unit bekannt machen und fertig wäre die Laube. Aber so einfach ist das wohl nicht. Solange es sich nur um Variablen handelt, kann ich ja einfach ein CLASS davorschreiben und ich hätte ein Klassenfeld. Was aber ist z.B. mit einem XML-Doc -- das muß ja dann irgendwo instanziiert werden. Mein Data_Provider sieht z.Z. so aus:
Delphi-Quellcode:
UNIT U_DataProvider;
INTERFACE USES XMLDoc, XMLIntf; TYPE TDP = CLASS PRIVATE CLASS VAR FXMLFileName : STRING; CLASS VAR FPresets : STRING; CLASS VAR FImageFileName : STRING; CLASS VAR XMLDoc : TXMLDocument; // Was damit tun?! PUBLIC CLASS PROPERTY XMLFileName : STRING READ FXMLFileName WRITE FXMLFileName; CLASS PROPERTY PresetsFileName: STRING READ FPresetsFileName WRITE FPresetsFileName; CLASS PROPERTY ImageFileName : STRING READ FImageFileName WRITE FImageFileName; END; IMPLEMENTATION END. |
AW: Design: globale Variable vs globale statische Klasse
Huuch!
Da fehlt ja noch ein Satz: Also, mir ist nicht klar: a) ist so ein Wunsch (globaler Data_Provider) sinnvoll b) Wie würde man z.B. so ein zentral XML-Document darin verwalten? Ich hoffe ich konnte mein Anliegen halbewgs verständlich machen. Danke & Gruß Jazzman |
AW: Design: globale Variable vs globale statische Klasse
In Delphi XE würde man dafür einen
Delphi-Quellcode:
und
class constructor
Delphi-Quellcode:
nehmen.
class destructor
|
AW: Design: globale Variable vs globale statische Klasse
Die technische Lösung wurde ja schon genannt. Ne Alternative für ältere Delphi-Versionen sind initialization und finalization. Aber um ehrlich zu sein: Schön ist das alles nicht. Letztendlich sind das auch wieder nur globale Variablen mit objektorientiertem Anstrich.
Das Problem an globalen Variablen ist ja die Kopplung über den gemeinsamen Speicherbereich. ==> Deine Units wissen zu viel voneinander und lassen sich außerdem nur schwer wiederverwenden. Das eigentliche Problem liegt also nicht darin, wie man die globalen Variablen kaschiert, sondern wie man deine Units so umstrukturiert, dass keine globalen Daten mehr notwendig sind... mfg Christian |
AW: Design: globale Variable vs globale statische Klasse
Wie schon gesagt wurde, dein Klassenkonzept stimmt nicht. Erweitere deine Klassen so, dass sie das XML Dokument als Attribut übergeben bekommen.
|
AW: Design: globale Variable vs globale statische Klasse
Zitat:
Bei D2009 bin ich mir nicht ganz sicher (ich glaub da gab's das schon, aber es funktionierte nicht) und davor kann man es eh vergessen. Aber praktisch kann man sowas auch über die Initialization- und Finalization-Abschitte erreichen.
Delphi-Quellcode:
, falls es öffentlich sein soll
CLASS VAR XMLDoc : IXMLDocument; // Achtung: I und nicht T
PUBLIC CLASS PROPERTY XML: IXMLDocument READ GetXML; // eventuell auch noch sowas Beim ersten Sugriff auf XMLDoc wird dieses erstellt.
Delphi-Quellcode:
Und durch das Interface wird es am Ende automatisch freigegeben.
if not Assigned(XMLDoc) then
XMLDoc := TXMLDocument.Create(...); Ich würde MSXML aber nicht zur Datenhaltung nutzen, sondern nur beim Speicheren/Lesen eine XML-instanz anlegen und danach wieder freigeben ... ansonsten die Daten halt in entsprechenden Variablen/Listen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:05 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