Properties, statische Variablen und eine Dateifrage

[Threin]

Hey,

daher ich trotz der zahlreichen Antworten, auch die, die ich im Internet gefunden habe irgendwie nicht den Sinn verstehe und auch ein paar Fragen habe, worauf ich leider nicht richtig die Antwort gefunden habe, frage ich mal hier.

1. Wann sollte man jetzt eigentlich Properties wirlich benutzen, also wann ist das wirklich ratsam?
Ja, es ist schon klar, das man diese gut nutzen kann für read-only oder write-only und um auch direkt zu prüfen, ob der Wert nicht passt oder ob dieser in einem bestimmten Bereich ist.
Aber was ist, wenn man sich da am Anfang noch nich sicher drüber ist, also wenn man am Anfang eine Prüfung für nicht notwendig gehalten hat?
Man kann ja zudem trotzdem von einer anderen Klasse aus nicht auf diese zugreifen, wie bei den Variablen auch oder irre ich mich da?
Man kann dann ja auch noch Databinding gut mit Properties benutzen und bei Variablen geht das ja nicht oder, also das der Wert direkt mit einer Textbox verbunden wird aber geht das auch von außen? (andere Klasse)

Das sind doch dann die wesentliche Vorteile oder nicht?

2. Wann sollte man das Schlüsselwort static benutzen? Es empfiehlt sich dann ja, dieses zu nutzen, wenn man die Klasse oder die Methode ja nur einmal braucht aber ist das der einzige Vorteil. Im nachhinein würde es dann ja auch keinen Sinn mehr machen, in einer Klasse, die man eh schon in einer anderen Instanziert hat, noch eine statische Methode zu machen?

3. Ich bin derzeit mit einem kleinen oder etwas größerem Projekt beschäftigt (nur Hobby)
Ich will dort Informationen speichern, also beispielsweise, wie oft die Anwendung schon gestartet wurde. Diese Daten sollen auch an zwei unterschiedlichen Orten angezeigt werden.
Dafür habe ich jetzt statische Variablen genommen, also z.B public static int wieOftGestartet = 0
Am Anfang wird dann die Datei eingelesen und der Wert in der Variable gespeichert und wenn man dann das Programm beendet, wird der Wert wieder in der Datei gespeichert aber wie geht man da am besten vor?
Sollte die Datei eine einfache Textdatei sein, wo dann die Werte drin stehen?
Ich wollte nicht nur die eine Sache speichern, sondern mehrere.

Sollte das ganze dann nachher so aussehen?

wieOftGestartet = 5
BearbeiteteNutzer = 124
usw ..

oder einfach nur so:
5
124
usw ..

oder ganz anderes?
Wie macht man das am besten und wie gesagt, welches Format sollte die Datei dann haben, wenn man solche Informationen speichern will?
Zudem müsste man die Datei ja dann auch noch einmal überprüfen, also ob diese nicht Fehlerhaft ist etc. wie macht man das am besten?
Mit Regex oder dergleichen?

Danke schon einmal im voraus.

[fanderlf]

Zu 1.: Properties sind auf jeden Fall sinnvoll. Du kannst später jederzeit etwas tun wenn jemand Deine Property setzt. Ausserdem genügt es auch dem Prinzip der Datenkapselung. Den wirklichen Zustand Deiner Klasse sollte niemand ohne Dein Einverständnis von aussen ändern können. Machst Du jedoch ein Feld public kann jeder von aussen den Zustand Deiner Klasse ändern ohne dass Du die Möglichkeit hast dies zu verhindern. Da in .Net noch nicht mal viel Aufwand betrieben werden muss um Properties zu benutzen, im Gegensatz dazu steht jetzt Java wo ich wirklich explizit jede Funktion anlegen muss, würde ich Dir dringendst dazu raten diese immer zu benutzen. Meistens sind es ja sowieso die Auto Properties und dafür ist auch nicht wesentlich mehr Tiparbeit nötig als für ein Feld. Letztlich ist eine Property sowieso eher eine Funktion als ein Datentyp.

Zu 2.: Ich persönlich finde es in .Net sehr unglücklich dass man static mit Sachen die nicht static sind vermischen kann. Grundsätzlich wäre mein Tip erstmal: Verwende static nur bei Klassen die keinen Zustand haben. D.h. Eine static Funktion sollte möglichst nicht auf ein static Feld zugreifen. Sollte das doch sein müssen, muss man wirklich vorsichtig sein was man dort tut. Webanwendungen erzeugen mehrere Threads die evtl. alle gleichzeitig auf die static Klasse zugreifen.

Zu 3.: Ich persönlich würde mir im Programm eine Klasse erstellen die alle diese Eigenschaften als Properties hat. Danach kann man das mit jedem x-beliebigen Format speichern und lesen (Beispiele: JSON .Net oder XML). Ich tendiere ganz klar zu JSON, da es sehr leichtgewichtig ist. Selbst machen würde ich das auf keinen Fall. Das sind gelöste Probleme, die diese Frameworks wesentlich besser lösen als man es selbst jemals könnte Der Ansatz mit der static Klasse ist Ok.

An Deiner Stelle würde ich mir mal das Thema Dependency Injection/Inversion of Control anschauen. Das könnte Dir an einigen Stellen bestimmt ganz gut helfen.

Falls Du noch Fragen hast melde Dich einfach

[Threin]

Hallo fanderlf,

danke für deine Antwort.
Du hast mir wirklich sehr weitergeholfen und irgendwie hat mich die Antwort auch sehr viel weiter gebracht, als die, die ich im Internet gefunden habe.
Zu 1 noch einmal eine kurze Frage:
Also würdest du mir empfehlen, Properties immer dann zu benutzen, wenn public-Variablen benötigt werden?

Zu 2
Ja, das finde ich irgendwie auch aber naja, deswegen kam ja auch die Frage auf.

Zu 3.
Naja, so ähnlich habe ich das ganze sogar schon vorliegen. Ich habe mir für diese Daten schon eine Klasse erstellt, was ja auch Sinn macht.
Kann ich den auch Properties als static deklarieren oder geht das nicht?
Die Methode in der Klasse müsste dann ja auch von außen aufrufbar sein bzw. die Variablen müssen von außen verfügbar sein.
Meintest du jetzt also das ich static Properties benutzen soll oder static-Variablen?

Noch einmal zur Datei:
Naja, mit JSON habe ich bisjetzt noch nicht gearbeitet aber mit XML schon.
Letztlich wäre die Datei dann aber auch lesbar, wenn ich diese als XML speichern würde. Du würdest mir dann ja sicherlich die Serialisierung empfehlen oder, also das ich die Klasse dann serialisiere.
Oder gibt es da irgendeine Möglichkeit die Datei zumindest vor Bearbeitung zu schützen?


Danke auf jeden Fall schon einmal für die sehr hilfreiche Antwort.

[Wernfried]

Bei deiner Frage, bzw. den Antworten solltest du noch eins bedenken: Du schreibst hobbymässig dein eigenes Programm, da hast du die volle Kontrolle und weisst was du machst, bzw. nicht machen solltest. Bei grösseren kommerziellen Programmen können jedoch sehr viele verschiedene Programmierer ihren Beitrag leisten, ohne dass die sich gerade am Schreibtisch gegenüber sitzen und jedes Detail absprechen könnten. In deinem eigenem Programm hast du in der Regel sehr viel mehr Freiheiten.

Gruss

[fanderlf]

Zu 1.: Ich würde auf jeden Fall für alle öffentlichen Eigenschaften einer Klasse immer Properties verwenden. Tut nicht weh und ab und an kann es echt ein Segen sein

Zu 3.: Ich hätte in etwa so ein Konstrukt:

[highlight=c#]
public class Settings
{
public int NumberOfTimesProgramWasOpened { get; set; } // muss nicht unbedingt so lange sein, schadet aber auch nicht
//... andere Settings die Du abspeichern möchtest
}

public static class SettingsLoader
{
private static string SettingsFilePath = "<Pfad zu meinem File>";

public static Settings LoadSettings()
{
var fileContent = File.ReadAllText(SettingsFilePath);
var settings = JsonConvert.DeserializeObject<Settings>(fileConten t);

return settings;
}

public static void SaveSettings(Settings settings)
{
var fileContent = JsonConvert.SerializeObject(fileContent);
File.WriteAllText(SettingsFilePath, fileContent);
}
}
[/highlight]

Das wäre die einfachste Variante. Falls Du mehrfach darauf zugreifen möchtest kannst Du Dir auch merken ob das File schon geladen wurde und dann das vorherige Ergebnis zurückgeben. Wenn Du es nur beim Programmstart einmal so brauchst tut das so schon alles was Du möchtest

Zum Dateizugriff: Muss diese Datei UNBEDINGT geschützt sein? Wenn ja dann kannst Du ja auch noch eine Verschlüsselung auf den String anwenden und ihn dann in die Datei schreiben. Da Du Dir aber, zumindest ohne größere Gegenmaßnahmen, den Source Code eines jeden .Net Programms anschauen kannst ist das auch nicht wirklich zielführend. Ich persönlich würde mir die Arbeit sparen. Was machst Du denn wenn jemand diese Datei einfach weglöscht? Dann geht der ganze Spaß wieder von vorne los. Alternativ könntest Du bestimmte Einstellungen auch in der Registry speichern. Dann liegen die Einstellungen wenigstens nicht dort wo sie jeder vollhonk findet Und die Leute die sie in der Registry finden sind auch fast schon in der Lage Deinen Source Code zu lesen und dann wirds wirklich schwierig mit verschlüsseln.

[luker]

Mein Senf zu 3.:
Sollte es sich hier um eine Anwendung in Windows Forms handeln, gibt es dafür etwas vorbereitetes. In den Projekteigenschaften unter dem Reiter "Einstellungen" kannst Du Variable mit Namen, Typ und Standardwert anlegen. Aus dem Programm heraus greifst Du über

Properties.Settings.Default.Variablenname

auf sie zu. Vorm Beenden des Programms

Properties.Settings.Default.Save()

nicht vergessen.
Und als "Bereich" solltest Du "Benutzer" einstellen, damit das Programm den Wert der Variable ändern darf.

Gespeichert wird das ganze in app.config, beim Ersten Start wird davon eine Kopie in den Tiefen der LocalApplicationSettings des startenden Benutzers angelegt (für jede Programmversion und jeden Benutzer einen neue), in der dann auch die geänderten Werte gehalten werden. Primitive Datentypen funktionieren ootb, für eigene musst Du eine Serialisierung in Text bereitstellen.

Mehr Informationen gibts in der MSDN.

[Threin]

@fanderlf
Hmm okay, dann denke ich, das ich das so machen werde.
Wie schon gesagt muss ich nur beim Start auf die Datei zugreifen, denn ansonsten speichert ja das Programm während der Laufzeit die Daten in der Variable und diese werden dann ja beim Beenden auch wieder hereingeschrieben.
Die Datei muss nicht unbedingt geschützt sein, sind ja eh nur Settings oder halt so ne Art "Statistik".
Naja, das mit der Registry ist ja eher unnötig und wenn jemand die Datei löscht, dann sind die Daten / Einstellungen ja eh futsch.
Nur was passiert denn, wenn der Inhalt dann beispielsweise von einem Nutzer geändert wird oder wenn eine Zeile fehlt?
Man müsste dann ja auch irgendwie noch den Inhalt der Datei prüfen oder? Mit Regex z.B ?
Ansonsten würde ja ein Fehler auftreten oder sollte man da dann irgendwie Standardwerte oder sonstiges nehmen?
Zudem müsste ich ja dann auch noch eine Methode schreiben, die dann auch diese Einstellungen nimmt, den das fehlt ja noch aber das kriege ich schon wohl hin.

Bist du eigentlich bei deinen Aussagen von WPF oder Windows Forms ausgegangen?

@luker
Bei WPF gibt es das nicht oder wie?
Da müsste man dann fanderlf's vorschlag nehmen oder halt seine eigene Lösung schreiben?

Würde das denn heißen, das ich auch wieder Properties erstellen müsste oder heißt das, das Werte von Properties in Variablen gespeichert werden oder sind das einfach nur Variablen?

[fanderlf]

Zu dem Thema von luker: Das sieht mir so aus als wären das normal .Net Eigenschaften eines normalen ausführbaren Projekts. Dort sind ja auch alle anderen Einstellungen zu Deinem Programm drin. Ich gehe davon aus dass das in WPF genauso ist wie in Windows Forms.

Zum Thema Standardwerte: Klar solltest du natürlich schauen ob die Datei da ist (File.Exists) und ob der Inhalt Deserialisierbar (exception beim deserialisierne abfangen) ist. Falls nicht erzeugst Du ein leeres Settings Objekt und schreibst Deine gewünschte Standardwerte rein. Gibt es denn tatsächlich einen Grund warum ein Benutzer das File ändern sollte? Ich persönlich würde mir darüber nicht so viele Gedanken machen. Das kommt aber auch ganz auf Deine Nutzer an.

[Threin]

Hey,

danke für die Hilfe und für die doch (meiner Meinung) sehr guten Antworten.

private const string version = "1.0";
private const string author = "T.J";
private const string website = "www.nochnichtda.de";

public static string Version
{
    get
    {
        return version;
    }
}

public static string Author
{
    get
    {
        return author;
    }
}

public static string Website
{
    get
    {
        return website;
    }
}

Naja, das habe ich um die Werte im Programm anzuzeigen, was ja recht normal ist denke ich.
Naja, der Wert wird ja nur lesend gebraucht.

Nunja, daher ich noch nicht viel mit Properties gearbeitet habe, wie macht man das so mit der Bennenung, also den Variablennamen mache ich normal klein aber wie macht man das bei dem Property? Eigentlich ähneln die Properts ja auch eher funktionen, wie du ja auch schon einmal gesagt hast, also deswegen groß oder so klein groß also theAuthor oder wie auch immer?

Ich habe noch nie an einem richtig großem Projekt mitgearbeitet und bin mir oft unsicher, deswegen frage ich.
Variablen mache ich immer timesStarted z.B also klein-groß, Funktionsnamen jedes neue Wort groß, also z.B LoadSettings() und Klassennamen auch groß aber wie macht man das bei Propertys? Der Rest ist doch so auch üblich oder? Ich habe auch schon ein paar mal, anstatt Support _Support gesehen. Konstanten schreiben ja auch viele glaube ich Groß oder, also AUTHOR z.B.
Hast du da irgendwelche Richtlinien, die du nimmst (Link vielleicht) oder hast du einen Rat oder jemand anders?

Zudem machen einige ja auch statische Variablen anders oder wenn man eine Klasse Instanziert und Listen etc. wie macht ihr das da?

[Ralf Jansen]

DIE Naming Guidelines.

Wenn du es einfach so hältst wie das im Framework gemacht ist bist du auf dem richtigen Weg. Alles was öffentlich ist schreibt man eigentlich groß und nur öffentliche Dinge sind da standardisiert. Die nicht standardisierte Absprache bei Klasseninternas wie Variablen, egal ob Klassen- oder Methodenvariablen, ist das man die kleinschreibt (camelCase). Da das auch für Parameter von Methoden gilt sieht man auch oft das Variablen mit underscore eingeleitet wird, aber trotzdem in camelcase also klein (_camelCase), um eventuelle Zuweisungen ohne this Pointer schreiben zu können den man dann braucht um gleichnamige Parameter und Variablen unterscheiden zu können. Die beiden üblichen Varianten sind als _camelCase oder camelCase aber nie _PascalCase . Öffentliche Konstanten sind eigentlich ein NoGo in .Net somit gibt es bei Konstanten auch keine richtigen Guidelines. Shouterstil (AUTHOR) ist eigentlich eher verpönt und wird eigentlich nur von Leuten benutzt die noch in der C/C++ Welt verwurzelt sind. Im Framework (auch wenn ich mir jetzt in die Quere komme mit dem Spruch das das ein NoGo ist) werden die auch einfach in PascalCase geschrieben. Beispiel Int32.MinValue.

Allgemein gilt das man durch das Naming gar nicht verdeutlichen will was das genau ist. Alles veröffentlichte wird einfach in PascalCase geschrieben. Ist doch für den Nutzer völlig egal ob zum Beispiel Int32.MinValue jetzt eine Variable, eine Konstante oder eine Property ist. Er muss eigentlich nur wissen ob die nur lesbar oder auch beschreibbar ist und dabei sollte ihm seine IDE helfen.

[fanderlf]

Ergänzend möchte ich noch sagen, dass man sich da für ein privates Projekt auch nicht kaputt machen muss. Es ist aber auf jeden Fall lobenswert dass Du Dir darum Gedanken machst. Das ist auch nicht überall selbstverständlich

[Threin]

Ergänzend möchte ich noch sagen, dass man sich da für ein privates Projekt auch nicht kaputt machen muss. Es ist aber auf jeden Fall lobenswert dass Du Dir darum Gedanken machst. Das ist auch nicht überall selbstverständlich

Naja, wenn dann will ich es auch direkt richtig machen.
Teilweise ist es ja dann auch noch Unternehmens-abhänging glaube ich, weil es da ja eigene Richtlinien gibt?

Hey,

wäre das denn so richtig mit den Settings oder Statistik?

private const string version = "1.0";
private const string author = "T. J";

public static string Version
{
    get
    {
        return version;
    }
}

public static string Author
{
    get
    {
        return author;
    }
}

und dann hier z.B ein Variable timesStarted z.B

private static int timesStarted= 0;

public static int TimesStarted
{
    get
    {
        return timesStarted;
    }
    set 
    { 
        timesStarted = value;
    }
}

In meinem Programm wird es dann nachher möglich sein, Kategorien zu erstellen und natürlich auch dazu Sachen einordnen.
Wie kann man das am besten machen, wenn man die Anzahl haben will aber auch jede Kategorie nachher auch einzeln anzeigen?
Ich wollte da eine Liste machen aber das würde dann ja nicht gehen, weil ich dann ja nur die einzelnen Strings z.B hätte.

public static List<string> categories = new List<string>();

Müsste man das dann mit einem zwei-dimensionalem Array machen oder gibt es da auch eine einfachere Möglichkeit?

Danke (noch einmal) für die Hilfe.

P.S: @fanderlf: Dein Posteingang ist voll.

[Ralf Jansen]

wäre das denn so richtig mit den Settings oder Statistik?

Wen du das als Beispiel für veröffentlichte Konstanten meinst dann ja. Für das konkrete Problem Version, Author aber überflüssig bis nicht hilfreich. Das Problem ist bereits durch AssemblyAttribute (die du in der AssemblyInfo.cs deiner Assembly findest) gelöst die man dafür benutzen sollte. Die werden dann natürlich auch von den Dateieigenschaften benutzt un ddamit auch von potentiellen Setups für diese Assembly.

Da die TimeStarted Property nix tut würde ich da auch einfach eine automatische Property verwenden. Dein Code funktioniert aber natürlich genauso.

Ich wollte da eine Liste machen aber das würde dann ja nicht gehen, weil ich dann ja nur die einzelnen Strings z.B hätte.

Hab ich nicht ganz verstanden. Aber wenn Kategorie mehr als der bloße string ist dann schreib dafür eine Category Klasse mit den notwendigen zusätzlichen Details und pack die in die Liste anstatt dem string.

[Threin]

Ja, die Datei oder die Klasse kenne ich auch schon, allerdings ist das ganze ja eher Firmenorientiert oder?
Mann kann zwar beim Copyright auch einfach nur seinen Namen eintragen aber so einzelne Infos sind da ja eher nicht so.
Naja, letztlich hast du ja wohl Recht aber eigentlich macht es ja auch keinen Unterschied oder?

Was ich aber nicht ganz verstehe ist, warum öffentliche Konstanten so schlimm sind, wie würdest du denn mit der Lösung (also meine) machen?

Ein Automatic Property ist ja das gleiche, wie was ich oben geschrieben habe oder?
Dann wird der Wert ja auch übernommen, wenn man die value ändert oder?

Naja, das übliche halt mit der Kategoire.
Man kann Kategorien erstellen und Themen oder was auch immer darin einordnen.
Das Problem ist ja, das wenn ich nur eine List nehme, das ich dann halt nicht bestimmen kann, wie viele Themen sich in einer Kategorie befinden, bzw, man kann ja dann gar keine Themen zuordnen.
Dafür müsste man dann ja z.B eine Struktur erstellen oder nicht?

Ich hätte auch noch zwei kleinere Fragen und das wäre es dann, denke ich zumindest.

1. Wie macht ihr das, wenn ihr mehrere Variablen desselben Typs anlegst, also z.B so:

public string id, firstName, lastName;

Man kann ja auch zudem sowas machen, also mit Initialisierung und Deklaration:

public int id = 0, PI = 3;

So war das glaube ich, allerdings mache ich sowas nicht.

Gibt es dafür eigentlich auch eine Guideline oder ist das einfach empfinden??

Ich habe das auch oft so gemacht, das ich dafür immer public string id, public string firstName etc. gemacht habe aber eigentlich ist das ja auch unnötig oder?
Macht man das dann pro neue Variable eine neue Zeile oder so?^^

Ist zwar so ne winzige Kleinigkeit aber das verbraucht ja auch bestimmt ein wenig mehr Ressourcen, wenn man immer public string, int usw. schreibt. (schätze ich)

2. Naja, ich kenne mich schon ein wenig mit der Trennung von Logik und GUI aus, allerdings habe ich noch nie ein Projekt komplett so umgesetzt.
Habt ihr da irgendwie ne Buchempfehlung? Ich glaube, es gibt da ja sogar mehrere Patterns nennt man das ja glaube ich.?
Bekannt sind da ja glaube ich vor allem MVC, ja .. und das andere fällt mir grad nicht ein.

Wäre nicht schlecht, wenn es ein Buch wär, weil ich auch gerne mal lese.

[fanderlf]

Ich denke Ralf wollte darauf hinaus wie der Compiler mit konstanten umgeht. Stell Dir vor Du hast 2 Assemblies. Assembly A referenziert eine Konstante von Assembly B. Wenn Du A jetzt baust wird einfach überall an die Stelle wo die konstante benutzt wird der konkrete Wert der konstante hingeschrieben, die Referenz verschwindet dann. Wenn Du jetzt aber den Wert der Konstante in Assembly B änderst ohne A neu zu bauen hat Assembly A immer noch den alten Wert der Konstante drin stehen. Ich denke deswegen sollte man die Finger von öffentlichen Konstanten lassen. Ich lese deswegen einfach generell die Finger vom const Schlüsselwort. Es gibt ja auch andere Möglichkeiten etwas als readonly zu markieren

Zum Thema Automatic Property: Ja intern ist das genau dasselbe wie das was Du oben stehen hast, nur eben weniger zum Tippen

Zur Themen und Kategorien Struktur:

[highlight=c#]
public class Kategorie
{
public string Titel { get; set; }
public string Thema { get; set; }
}

public class Thema
{
public string Titel { get; set; }
public string Beschreibung { get; set; }

public IList<Kategorie> Kategorien { get; set; }
}
[/highlight]

So in etwa könnte so etwas aussehen, auch wenn ich Dir von der gegenseitigen Referenzierung abraten würde. Das kommt aber auch darauf an wie Du das ganze benutzt.

Zu den Variablen: Ich würde jeder Variable eine Zeile spendieren. Zumal Dir Tools wie ReSharper dort viel Tiparbeit abnehmen. Von den Resourcen her dürfte das überhaupt keinen Unterschied machen. Der Compiler macht hoffentlich am Ende aus allen Varianten dasselbe Kompilat.

Zu MVC: MVC in Reinform macht heutzutage eigentlich kein Framework und ich würde Dir auch nicht raten stur das MVC Pattern aus dem Buch zu implementieren. Die meisten modernen Frameworks unterstützen vielfältigste Arten von DataBinding/Templating. Da sollte die Reise eher hingehen. Mir gefallen die Frameworks immer recht gut die so etwas wie ein ViewModel haben und der BindingCode im UI Code steht. Das wären in .Net z.B. Windows Forms (wenn auch nicht ganz schön), WPF oder ASP.NET MVC. Von ASP.NET WebForms würde ich die Finger lassen. Je nachdem was Du machen willst würde ich Dir zu WPF (Desktop Rich Client) oder ASP.NET MVC (Web) raten. Vermutlich ist für Dich erstmal auch Desktop leichter, weil beim Web nochmal ein Overhead mit HTML, Javascript, Request, Stateless Seite usw. dazu kommt.