globale variable in C#?

[Elvis]

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 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 von Der_Unwissende:

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

Sorry, hab' chronische OTitis...

Zitat:

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

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 ... 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.