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.