globale variable in C#?

[richard_boderich]

moin,

ich habe einen boolean wert auf den ich 3 unterschiedlichen ereignissen zugreifen muss.
eine extra klasse dafuer erscheint mir jedoch zu sehr uebertrieben. gibt es globale variablen in c# oder vergleichbare konstrukte und wo definiere ich diese.

richard

[stj]

Mit globalen Variablen machst Du Dir in der DP eigentlich fast nur Feinde, die dann zum xten Mal wieder über die Vor- und Nachteile von globalen Variablen herziehen. Spreche aus Erfahrung!

Stell die Frage für Dein Problem besser irgendwie anders!

msfg

[ArmyMan]

Auch wenn es nicht gerade etwas ist das man benutzen sollte gibt es natürlich einen Workaround:

Eine Neue Klasse erstellen mit einem Namen z.B. globalVars wo dann alle "globalen" Variablen reinkommen.

Code:

public class globalVars
{
  public String var1;
...
}

Dann kann man über einen aufruf

Code:

globalVars.var1

die gewünschte Variable auslesen/setzen.

Hoffentlich konnte ich helfen.

Greetz

[MagicAndre1981]

Hallo Richard,

ne in C# gibts keine globalen Variablen mehr. Schau dir mal das Singleton-Pattern an, vllt ist das was für dich.

[richard_boderich]

mhh also das mit der globalvars klasse funktioniert nicht. er bringt eine compilerfehlermeldung
"objectverweis erforderlich"

und den begriff singelton finde ich leider nicht in der c# sprachreferenz vom VS2005?

kannst du mir da eventuell auf die spruenge helfen?

richard

[mkinzler]

Ein Singleton-Pattern sorgt dafür, daß nur eine Instanz einer klasse gebildet werden kann.

[richard_boderich]

danke fuer die erklaerung :)
heisst das unter VS2005 vielleicht anders? ich finde es nicht in der sprachreferenz *ratlos bin*

richard

[mkinzler]

Das Singleton ist ein Design-Pattern und kein direktes Feature einer Programmiersparche.
http://www.aspheute.com/artikel/20040922.htm

[Elvis]

Zitat:

Zitat von richard_boderich

mhh also das mit der globalvars klasse funktioniert nicht. er bringt eine compilerfehlermeldung
"objectverweis erforderlich"

und den begriff singelton finde ich leider nicht in der c# sprachreferenz vom VS2005?

Ist ja auch kein Sprachfeature, das ist eines der klassischen GoF Patterns. ;)
Ein Singleton it ein Konstrukt, dass immer nur eine Instanz einer Klasse zulässt.
In C# ist das relativ easy, naja in fast jeder .Net-Sprache dürfte das in wenigen Zeilen zu machen sein.

Code:

public class Miep
{
  private  Miep(){}

  public static readonly Miep Instance = new Miep();
}

Aber das löst dein Problem nicht oder nur ziemlich unschön.
Ein normaler Application developer sollte IMHO keine Singletons anlegen müssen. Singleton sind oft ein Zeiichen von schlechtem Design und Code, der sie benutzt skaliert definitiv schlecht.
Multi threading wird dir irgendwann kaum Performancegewinn bringen, da dich die Synchronisierung auffrisst. Außerdem versiehst du Code damit indirekt mit State, wodurch er nicht mehr in einem anderen Context zu gebrauchen ist.
Singletons, genau wie globale Variablen oder öffentliche, beschreibbare statische Properties sind ein Zeichen, dass jemand versucht State zu halten ohne ihn an etwas zu fixieren.
Wie oben gesagt, Code, der durch globale Variablen oder ingletons infiziert ist, wird schlecht skalieren und er wird nur schwer wiederverwendbar sein. ;)

[Jürgen Thomas]

Zitat:

Zitat von Elvis

Ein normaler Application developer sollte IMHO keine Singletons anlegen müssen. Singleton sind oft ein Zeiichen von schlechtem Design und Code

@Elvis,
tut mir leid, da möchte ich Dir widersprechen: Es gibt immer wieder Situationen, in denen ein und dieselbe Variable an verschiedenen Stellen im Programm (Formulare, Datasets oder andere Klassen) benötigt werden. Beispiele: UserName (der durch ein eigenes Login registriert wird), Programmeinstellungen (die nur einmal gelesen werden), Liste der geöffneten Formulare, Nachschlagetabellen. In solchen Fällen sind Singleton-Klassen durchaus nützlich. (Dieses Vorgehen würde wohl auch kaum propagiert, wenn es nur eine Abkürzung für schlechte Programmierer wäre...)

Man kann zwar sehr viel über Delegates regeln (wie Du es vermutlich empfiehlst), aber auch dabei musst Du Dich um die Sichtbarkeit kümmern.

@Richard
Zusammenfassung mit ein paar Erklärungen für die anderen Hinweise:

Zitat:

Zitat von richard_boderich

mhh also das mit der globalvars klasse funktioniert nicht. er bringt eine compilerfehlermeldung "objectverweis erforderlich"

Für die genannte Klasse hattest Du keine Instanz erzeugt; der Verweis darauf fehlte. Aber eine 'globale Variable' kann durch eine statische Variable einer globalen Klasse ersetzt werden; das wäre folgender Vorschlag gewesen:

Zitat:

Zitat von ArmyMan

Eine Neue Klasse erstellen mit einem Namen z.B. globalVars wo dann alle "globalen" Variablen reinkommen.

Code:

public class globalVars
{
  public static String var1;   //  static eingefügt von Jürgen Thomas
...  }

Dann kann man über einen aufruf

Code:

globalVars.var1

die gewünschte Variable auslesen/setzen.

Zitat:

Zitat von richard_boderich

und den begriff singelton finde ich leider nicht in der c# sprachreferenz vom VS2005?

Mir wurde der Begriff vor etwa drei Monaten auch nur hingeworfen ohne weitere Erläuterung. In #D haben die freien Entwickler (auch auf diesem Weg ein herzliches Dankeschön!) eine Musterklasse bereitgestellt:

Code:

namespace JThomas.DGW.Common   {
public sealed class SingletonClass1   {
    private static SingletonClass1 instance = new SingletonClass1();
    public static SingletonClass1 Get_Instance {
   get {   return instance;   }
    }
    private SingletonClass1()   {
        //  hierher - private! - gehört der Konstruktor-Code
    }
}  }

Auf diese Klasse wird dann von beliebiger Stelle im Programm wie folgt zugegriffen:

Code:

//  Deklaration
private JThomas.DGW.Common.SingletonClass1 sc;
//  Zugriff auf die einzige Instanz
sc = JThomas.DGW.Common.SingletonClass1.Get_Instance;

Wenn sie noch nicht existiert, wird sie durch 'private static = new' zunächst erzeugt; auf jeden Fall wird dadurch ein Verweis auf diese einzige Instanz (und damit auf alle öffentlichen Variablen) zur Verfügung gestellt.

Ich hoffe, dass meine Erklärungen hilfreich waren (und ich niemandem auf die Füße getreten bin).

Gruß Jürgen

[Elvis]

Zitat:

Zitat von Jürgen Thomas

@Elvis,
tut mir leid, da möchte ich Dir widersprechen: Es gibt immer wieder Situationen, in denen ein und dieselbe Variable an verschiedenen Stellen im Programm (Formulare, Datasets oder andere Klassen) benötigt werden. Beispiele: UserName (der durch ein eigenes Login registriert wird), Programmeinstellungen (die nur einmal gelesen werden), Liste der geöffneten Formulare, Nachschlagetabellen. In solchen Fällen sind Singleton-Klassen durchaus nützlich. (Dieses Vorgehen würde wohl auch kaum propagiert, wenn es nur eine Abkürzung für schlechte Programmierer wäre...)

Nope, sie werden dann am meisten eingesetzt wenn man rein nach RAD vorgeht und somit Herangehensweisen ausschließt, die sich als wesentlich robuster und wartbarer herausgestellt haben.
Dein Beispiel mit den Enstellungen ist da ganz niedlich, denn der Settings Provider in .Net 2.0 besitzt eine Default Instanz, die man benutzen kann wenn man will. Aber er ist kein Singleton, d.h. du kannst eine zweite Instanz anlegen und vllt woanders speichern.
Dadurch dass er kein Singleton ist, wird wohl kaum jemand auf die dumme Idee kommen und ständig Settings.Default benutzen, sondern lieber die jeweilige Settingsinstanz übergeben oder eine Eigenschaft davon zu halten.
Du hast da glaube ich einen Thread geöffnet, der sich damit beschäftigt. Ich werde den mal bei Gelegenheit rauskramen, aber ich bin mir ziemlich sicher, dass du weder eine globale Variable noch ein Singleton brauchst.
Oft reicht es schon von dem eingefahrenen Standpubkt abzuweichen, Forms als zentralen Teil der Anwendung zu sehen. Sie sollten es nämlcih nicht sein. Der View sollte eigentlich strunzdumm sein und sich nur um das kümmern was die Darstellung der Daten angeht. Je mehr Code du in den View steckst umso mehr Code kannst du nehmen und wegschmeißen wenn größere Änderungen anstehen oder du etwas Ähnliches in einem anderen Projekt machen willst.

Zitat:

Man kann zwar sehr viel über Delegates regeln (wie Du es vermutlich empfiehlst), aber auch dabei musst Du Dich um die Sichtbarkeit kümmern.

Events sind oft ein netter Weg eine Art indirektes Interface zu schaffen über die zwei komplett entkoppelte Klassen über eine dritte Glue-Klasse lose gekoppelt werden können. Richtig.
Aber sie sind nicht unbedingt notwendig. Zum Beispiel empfehle ich in native Delphi keine Events zu nutzen, da es da keine Multicast delegates gibt. Trotzdem kann man einfach über eine durchdachte Struktur von "wer sieht wen" die Probleme von globalen Variablen aus der Welt schaffen, in .Net genau wie in native Delphi.

[Der_Unwissende]

[OT]
Nur mal der Hinweis, dass ihr schon ziemlich OT seid.

Was das Singleton-Pattern angeht, so kann es durchaus sinnvoll sein es umzusetzen, es kommt halt nur sehr stark drauf an, was man machen muss. Gibt es eine sehr exlusive Ressource, deren Zugriff nun mal über eine Klasse gekapselt werden muss und die wirklich nur einmal existiert, so lohnt sich hier ein Singleton-Pattern. Für jeden Zugriff eine eigene Instanz anzulegen wäre alles andere als sinnvoll.
Es mag sicherlich Beispiele geben, wo man auch gut ohne auskommt, aber ein

Zitat:

Zitat von Elvis

Ein normaler Application developer sollte IMHO keine Singletons anlegen müssen

ist denke ich doch schon zu stark pauschalisiert. Wie alle Designpattern kann man es halt verwenden oder nicht und nur wenn man weiß wie und wo bringt es Vorteile. Aber der Sinn liegt ja auch darin, ein Singleton nicht als Ersatz für globale Variablen zu missbrauchen, sondern das Problem zu lösen, dass man nur eine Instanz erzeugen darf.
Gut, Elvis sagte ja auch, dass es nur häufig auf schlechtes Design schließen lässt, nicht immer.

Was hier wirklich für schlechtes Design sprechen würde wäre auch imho, dass man alle "globalen" Variablen in eine Klasse steckt. Allein das Variablen, die nichts weiter mit einander zu tun haben einfach nur in einer Klasse stecken, damit sie leicht erreichbar sind...
Da sollte man sich dann doch mal dringend die Grundlagen der OOP anschauen und fragen ob es wirklich global sein muss? (geht nicht direkt, aber auch Workarounds müssen selten sein) und natürlich auch nochmal, wie man Klassen so designt.
[/OT]

Was die eigentliche Frage angeht, kannst du hier noch etwas genauer sagen wie du das meinst? Hast du drei komplett unabhängige Ereignisse die eine Benachrichtigung auslösen? Oder passiert etwas (was diesen boolschen Wert setzt), das 3 Ereignisse auslöst? Dann natürlich auch die Frage, gehört dieser boolsche Wert nicht zu einer Instanz? Was genau soll der denn anzeigen?
Ich denke da steckt bei dir im Moment wirklich eher ein Denk/Designfehler drin, als dass du wirklich was globales brauchst.

[Elvis]

Zitat:

Zitat von Der_Unwissende

Nur mal der Hinweis, dass ihr schon ziemlich OT seid.

Sorry, hab' chronische OTitis... :duck:

Zitat:

Es mag sicherlich Beispiele geben, wo man auch gut ohne auskommt, aber ein

Zitat:

Zitat von Elvis

Ein normaler Application developer sollte IMHO keine Singletons anlegen müssen

ist denke ich doch schon zu stark pauschalisiert. Wie alle Designpattern kann man es halt verwenden oder nicht und nur wenn man weiß wie und wo bringt es Vorteile.

Wie alle Pauschalisierungen, war auch meine zu ... :gruebel: pauschal. ;)
Auch der Ausdruck "normaler App Dev" dürfte im allgeimen Verständnis einwenig unscharf umrissen sein.
Das was ich unter einem "normalen App Dev" verstehe passt aber IMO zu meinem Statement. Jemand der hauptsächlich APIs konsumiert und darauf aufbauend eine App schrauben soll, sollte einfach keine Singletons brauchen. (Die Entscheidung sollten diejenigen übernehmen, die die APIs bereitstellen)
Das Problem ist einfach, dass sich viele in dieser Gruppe nicht wirklich mit SW Architektur auseinandersetzen und gerne den Weg des (vermeintlich) geringeren Widerstandes gehen. (Der klassische Connection-uff'n-Form-Zieher sozusagen)

Zitat:

Gut, Elvis sagte ja auch, dass es nur häufig auf schlechtes Design schließen lässt, nicht immer.

Exakt, dein Beispiel mit der Resource, die nur einmal existiert, ist so eine Ausnahme.