Laden...

Benutzung statiscer Variablen

Erstellt von Badscher vor 17 Jahren Letzter Beitrag vor 17 Jahren 2.672 Views
B
Badscher Themenstarter:in
24 Beiträge seit 2005
vor 17 Jahren
Benutzung statiscer Variablen

Hallo,

ich habe eine Frage zur Struktur meines Programms.

Ich mehrere unterschiedliche Objekt und Variablen, wie zum Beispiel ein Verbindungsaufbau zu einem Server (Connection), ein Excelobjekt (ExcelApp), oder eine Variable, welche mir alle registrierten PlugIns vorhält und mehrere andere Variablen zur Verarbeitung der Daten.
Da ich einige der oben genannten Objekte/Variablen in unterschiedlichsten, voneinander unabhängigen Situationen während des Programmablaufs benötige, habe ich mir eine Klasse programmiert, welche mir die Daten in statischen variablen vorhält. So kann ich jederzeit die Varibalen schreiben und lesen.

Meine Frage ist jetzt, ob es eine elegantere Lösung gibt, oder ob dieser Weg so an sich ganz gut ist.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Ich nenne sowas immer: Globale Variablen für Arme. 😉

Die Alternative ist natürlich, alles als Parameter durchzureichen (bzw. einem Property zuzuweisen) und irgendwo innerhalb von Objekten die Referenz abzulegen. Wenn das ist deinem Code kompliziert und aufwändig ist, dann ist das ein sicherer Hinweis darauf, dass dein Modell nicht optimal ist. Die Verwendung globaler Variablen ist in jedem Fall ein "quick and dirty"-Hack, was nicht heisst, dass "quick" nicht manchmal das entscheidende Argument gegen "dirty" sein kann. Nur sollte man sich dessen bewußt sein.

Da von bestimmten Objekten sicher nur eine Instanz erzeugt werden darf (z.B. Connection) bietet sich hier das Singleton-Pattern an. Das hat aber mit dem "global"-Problem nix zu tun und löst dies auch nicht.

B
Badscher Themenstarter:in
24 Beiträge seit 2005
vor 17 Jahren

Ja, an das Singleton habe ich auch schon gedacht. Das funktioniert gut für die Connection oder für die ExcelApp. Aber gerade für die Liste der PlugIns, welche ja keine eigene Klasse ist, dachte ich mir, dass diese Lösung ok ist.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Aber wie gesagt: Singleton hat mit deinem eigentlichen Problem überhaupt nix zu tun.

Auf eine globale Variable (bzw. statische Klassenmember) kann jeder zugreifen, der die Klasse sieht. Das ist tendenziell jeder. DAS ist das Problem und hat mit Singleton nix zu tun. Es ist viemehr ein klassisches Strukturierungsproblem. In einem gut designtem System gibt es keinen Bedarf nach globalen Variablen..... höchstens nach Singletons (aber nur die!), die ja auch irgendwie "global" sind.

M
81 Beiträge seit 2006
vor 17 Jahren

hallo svenson

ich hatte schon ähnliche probleme, und bin bei diesem thread sofort neugierig geworden

was meinst du mit?

Die Alternative ist natürlich, alles als Parameter durchzureichen (bzw. einem Property zuzuweisen) und irgendwo innerhalb von Objekten die Referenz abzulegen.

heisst das, dass die klasse, die "zuoberst" im klassenmodell steht, die connection erstellt und dann nach "unten" durchgibt? dass also jede klasse, die ein objekt einer anderen klasse erstellt, dieser neuen klasse die connection übergibt?

es interessiert mich allgemein, ich habe nicht jetzt dieses problem.

Danke, Gruss
Mischa

49.485 Beiträge seit 2005
vor 17 Jahren

Hallo mischa,

das hat weniger was mit zu oberst im Klassenmodell zu tun als mit dem Durchreichen per Paramter entlang der Aufrufkette.

herbivore

S
8.746 Beiträge seit 2005
vor 17 Jahren

So ist es. Das heisst natürlich nicht, dass du das Objekt (nehmen wir mal Connection) jedesmal komplett durchschleifen musst. Statt jedesmal das Connection-Objekt in jede Anfrage zu stecken, erzeugst du ein Command-Objekt, welches ein Connection-Property aufweist. Dies weist du einmalig zu und kannst dann in Folge das Command-Objekt x-mal nutzen (mit immer dem gleichen Conection-Objekt). Noch besser ist es, wenn du Zuweisung im Rahmen einer Factory-Methode direkt bei der Objektkonstruktion erfolgt.

Statt also zustandlos immer alle benötigten Daten in eine Funktion reinzureichen, speichere die "konstanten" Daten in dem Objekt zwischen, dessen Methoden diese Daten brauchen. Aber eben nicht als globale Objekte, sondern nur dort, wo sie auch konkret genutzt werden.

M
81 Beiträge seit 2006
vor 17 Jahren

danke erstmals. werde mich erstmals über Factory-Methoden schlaumachen, bevor ich hier weiterfrage.

wenn ich dich aber richtig verstehe, habe ich am schluss noch ein command-objekt, das ich immer wieder verwende. nur, wie macht man das dann z.B. bei einem DataAdapter? der braucht ja u.U. vier commands (select,insert,update,delete). und mein command kann ja nicht gleichzeitig mehrere befehle enthalten.

4.221 Beiträge seit 2005
vor 17 Jahren

Original von svenson

Statt also zustandlos immer alle benötigten Daten in eine Funktion reinzureichen, speichere die "konstanten" Daten in dem Objekt zwischen, dessen Methoden diese Daten brauchen. Aber eben nicht als globale Objekte, sondern nur dort, wo sie auch konkret genutzt werden.

Dies hat auch den Vorteil, dass man mit weniger Aufwand skalieren kann, wenn dann plötzlich eine DB-Connection nicht mehr reicht.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

4.221 Beiträge seit 2005
vor 17 Jahren

Original von mischa

wenn ich dich aber richtig verstehe, habe ich am schluss noch ein command-objekt, das ich immer wieder verwende. nur, wie macht man das dann z.B. bei einem DataAdapter? der braucht ja u.U. vier commands (select,insert,update,delete). und mein command kann ja nicht gleichzeitig mehrere befehle enthalten.

Dann hast Du einen DataAdapter mit 4 Commands und alle Commands verwenden dieselbe Connection

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von mischa
wenn ich dich aber richtig verstehe, habe ich am schluss noch ein command-objekt, das ich immer wieder verwende. nur, wie macht man das dann z.B. bei einem DataAdapter?

Hmm, ich hätte wohl doch nicht ausgerechnet Connection verwenden sollen. Mir ging es jetzt hier nicht um die konkrete Umsetzung und den Vergleich mit .NET, sondern nur im die Tatsache, dass man oftmals "konstante" Parameter besser in einer Art Initialisierungsphase einem Objekt mitteilt. So muss man das Datum nicht als Methodenparameter durchschleifen. Das reduziert zum einen die Parameterlisten und performt auch besser. Damit sind diese Objekte immer noch irgendwie "global" (nämlich für alle Methoden, die es brauchen), aber eben sauber in einem Objekt gekapselt.

Meiner Erfahrung nach reicht schon dieser Technik aus, um fast allen globalen Variablen den Gar aus zu machen, da diese fast immer aus der Not geboren werden, die da heisst: "Oh Mann, wenn ich das jetzt nicht global mache, muss es es überall durchschleifen...". Das gilt aber nur, wenn das Modell zu flach ist und daher keine Möglichkeiten bietet um Zustände zu speichert. Globale Variablen bedeuten auch fast immer: Zu wenige Klassen. Zu wenig Struktur.

M
81 Beiträge seit 2006
vor 17 Jahren

hmm, langsame beginne ich zu verstehen. vielen dank für diese lektion in sauberem design! werde ich sicher umsetzen (versuchen) in einem nächsten projekt.

Danke, Gruss
Mischa