Wie speichere ich Daten die jederzeit benötige? Warum soll man keine Public Variablen nutzen?

@OlafSt
Nö, niemand verlangt das.
Da hst Du ein Problem mit dem Aufbau der Klasse. Aber ich verstehe nicht, wieso es Dir in diesem Fall helfen würde, stattdessen ein Feld Public zu machen. Das Feld kann ja genausogut Private sein und stattdessen kannst Du einfach die Property Public machen und direkt auf das Feld zugreifen:

Dann wird jedes Mal nur auf das Feld zugegriffen.
Und ich trau mich auch zu sagen, dass der JIT-Compiler für einfache Getter-Methoden schlussendlich Inlining betreibt. Dann verschwindet der "unnötige" Methodenaufruf komplett.

Was aber vien interessanter ist: Man kann bei einem Feld nicht darauf reagieren, wenn es verändert wird. Man müsste von außen nochmal extra eine Methode aufrufen, damit die Klasse über die Veränderung aufmerksam gemacht wird. Was natürlich total bescheuert wäre.
Und manchmal will man gar nicht, dass man was von außen verändern kann, sondern dass man es nur von innen verändern kann. Dann funktionieren ReadOnly Felder auch nicht.

OlafSt schrieb:

Was bieten die GVA als Alternative an - denn es muß ja eine geben ?

Naja, sone Variable CanSaveToDB darf nicht global sein, sondern ist logischerweise eine Objekt-Variable des Datenmodells.

Und die Logik, die bestimmt, ob gesavet werden kann, sollte ebenfalls Bestandteil des Datenmodells sein - sodass ein Datenmodell-Objekt gewissermassen selber "weiß", ob es sich speichern kann oder nicht.
Und wenn es das selber weiß, dann sollte CanSaveToDB auch nicht mehr eine Variable sein, sondern eine Readonly Property, damit niemand einfach von aussen zugreift, und es auf True setzt, auch wenns garnet stimmt.

So ungefähr geht OOP-Denke.

Was bieten die GVA als Alternative an - denn es muß ja eine geben ?

Properties, wenn die Eigenschaft für die Außenwelt wichtig ist.

Edit: huch Seite 2 nicht gesehen.

Hallo,
globale Varablen sind nur dann problematisch, wenn man an gewisse Grenzen stößt. Beispiel 1: mache die Scheifenvariable i global.
Ergebnis: nach ca. 3 Seiten geschriebener Code ist dein Programm unbrauchbar.
Ich habe viel mit Programmen zu tun, die durch mehrere Hände gegangen sind und älter sind als das Durchschnittsalter der User hier im Board.
Ab einer gewissen Größe wird letztendlich jedes Programm unübersichtlich. Mit Objektorientierung zögert man das nur hinaus.
Ich habe auch erlebt das OO mehr schadete als nutzte.
Ein unübersichliches Program zu verändern ist problematisch. Wo soll ich die Codeänderungen nun vornehmen? Hier, dort, da auch. Und nachdem nun ca. 50 Codeänderungen mit den damit einhergehenden Dopplungen implementiert sind, beginnt das große Desinteresse an Codequalität.
Btw:
wenn ihr globale Variablen so verteufelt, solltet Ihr keine Datenbank einsetzen, das ist nämlich das globalste von allem: Mehrere Programme können gleichzeitig drauf zugreifen.
Und das ist auch ein Besipsiel, wieso globale Varablen und Multitasking nicht gut miteinander können: Der Datenbankler hat Angst vor Deadlocks.

@OlafSt

die Alternative ist, dass du deine GVA in eine Klasse steckst und dort als Public dimensionierst. Das ändert zwar nicht viel, aber die Puristen wird's etwas beruhigen ;-). Der kleine Umweg über die Klasse wird nicht viel Rechenzeit kosten.

Klaus

Nun, ich hab kein Problem damit, mein CanSaveToDB in eine Klasse zu packen. Nicht mal mit dem ReadOnly hätte ich ein Problem.

Aber, um an mein CanSaveToDB heranzukommen, muß ich die Klasse instanzieren. Und da ich von allen Teilen des Programms gern darauf zugreifen möchte, muß diese Instanz - na ratet mal - global verfügbar sein. Und schon haben wir wieder etwas, das die GVA-Fraktion nicht haben will...

Schlußendlich wird man um globale Variablen nicht herumkommen, egal wie sehr man in Rumpelstilzchenmanier mit dem Fuß aufstampft Letztendlich geht es um die streckenweise völlige Disziplinfreiheit von Programmierern. Die dann wild in solchen Globals herumfuhrwerken, ohne zu wissen, was sie da tun und anrichten. Vermutlich funktionieren globale Variablen deswegen für mich so wunderbar - weil ich mit den Dingern sparsam umgehe und nur für Queues (Multithreading) und halt solche Einstellungsgeschichten (bei Programmstart einmal gesetzt, nie wieder geändert) benutze.

Du denkst halt nicht objektorientert.

Wenn im ganzen Programm "CanSaveToDB" verfügbar ist... was kann ich denn in der Datenbank speichern? Tomaten? Das Käsebrot von gestern? Handwerker?
Ach nur bestimmte Daten sollen in der Datenbank gespeichert werden. Dann muss natürlich das Objekt, welches die Daten beinhaltet, wissen, ob speichern oder nicht. Also gib der Klasse die Eigenschaft.

Du verstehst da glaub ich etwas falsch. Es geht im Kern nicht darum, dass eine Variable in einer Klasse sein muss (das muss sie so oder so, egal wie ihrs hier nennt, es gibt in .Net gar keine Variablen die keine Member sind).
Es geht darum, so zu programmieren, dass du sowas

OlafSt schrieb:

Und da ich von allen Teilen des Programms gern darauf zugreifen möchte

nicht wollen sollst. Es ist nicht wünschenswert, ein Programm so zu gestalten, dass von überall auf alles zugegriffen werden muss, denn das führt in der Tat sehr schnell zu großer Unübersichtlichkeit, gerade wenn mehrere Leute unabhängig voneinander dadran rumwerkeln und damit kreuz und quer im Programm was verändern.
Stattdessen sollte ein Programm gewisse Teile strikt voneinander trennen, sodass einzelne beliebig angepasst oder gar ganz ausgetauscht werden können, ohne die anderen zu beeinflussen. So können einfach Wartungen und Erweiterungen auch von Personen, die sich im Quellcode nicht oder kaum auskennen, durchgeführt werden, weil nicht Programmabläufe quer durch den gesamten Code gesucht werden müssen.
Sieh dir z.B. einmal an, wie ein WPF-Programm, das sich durchgehend streng an MVVM hält, aussieht. Irgendwas "globales" wirst du da drin nicht finden, egal wie komplex es wird, da die Interaktion der einzelnen Programmteile (in diesem Beispiel speziell Model, Viewmodel und View) mächtig genug ist, um auf solche Mittel verzichten zu können.

nö - ich stimme Olaf vollkommen zu: Alle diese dolle Sache mit Repository, Inversion Of Control - Container, Data Access-Layer, Dependancy-Injection, Service or whatever - alles Beschönigungen und Verschleierungen dafür, dass man insbesondere Anwendungsdaten sehr wohl letztendlich in globalen Variablen hält.

Und @Artentus - eine Shared Variable ist kein Object-Member, also ein Member schon, aber eben kein Object-Member.

Und allerdings gibt es in fast jedem Programm - und insbesondere auch in MVVM-Wpf-Anwendungen - globale Elemente.
Zumindest ich hab immer ein MainViewmodel, und davon lege ich eine Instanz in den Resourcen der App.Xaml an.
Mit dieser Vorgehensweise stelle ich das MainViewmodel ganz bewust global der gesamten Anwendung zur Verfügung.

Der Punkt ist - in meinen Augen jedenfalls - dass ich zusehe, dass es das einzige ist.
Hab ich auch schon in post#22 auf Olaf geantwortet: Eine globale, eigene CanSaveToDB-Variable gäbe es bei mir nicht, denn bei mir ist immer das ganze Datenmodell global, aber das ist auch das einzige bei mir globale Objekt.
(Abgesehen von den Settings, und verschiedenen anderen Sachen, die Global zu machen es MS gefiel - aber da kann ich ja nix für).

Also nicht so tun, als bräuche man es gar nicht, sondern wo man es notgedrungen eben doch braucht, es sparsam und verantwortungsvoll einsetzen.

Wohltuend finde ich auch Coldfires Einlassung: Grosse Systeme werden nunmal unübersichtlich.
Man mag ein gutes Instrumentarium haben, um dem irgendwie Herr zu werden, aber es gelingt nur so recht und schlecht, und je fetter das System, desto mehr Strukturierungs-Aufwand wird man treiben, und wird dennoch immer schwieriger.

ErfinderDesRades schrieb:

Zumindest ich hab immer ein MainViewmodel, und davon lege ich eine Instanz in den Resourcen der App.Xaml an.
Mit dieser Vorgehensweise stelle ich das MainViewmodel ganz bewust global der gesamten Anwendung zur Verfügung.

Der Punkt ist - in meinen Augen jedenfalls - dass ich zusehe, dass es das einzige ist.

Wenn etwas das einzige sein soll, dann stellt man das in einen OOP Projekt jedoch meistens über ein Pattern wie z.B. das Singleton Pattern um. Ob man solch als global bezeichnen mag... nun ja. Wie man meint.

Natürlich global - also wenn ein Singleton Public ist, dann ist er global - von überall zugreifbar - was kann sonst die Bedeutung von "Global" sein?

Die Sache bei MVVM ist nur: das Viewmodel selbst ist das höchsgestellte ausführende Element in der Anwendung und wird nur einmal ganz zu Beginn an den View gebunden, danach gibts keine globalen Zugriffe mehr.