Wert oder Zustand nach einmaligem Setzen einfrieren

Hallo Gemeinde,

ich möchte den Wert eines Member welcher auch in eine Datenbank persistiert wird einfrieren, also ihn keinesfalls seiten meines Programms ändern lassen.

Nun meine Frage:
wenn ich den Typ nullable mache, verriegele ich dann das Ändern des Member am besten über ein entsprechendes Property oder schreibe ich besser separate getter- und setter-Methoden?

Viele Grüße

Jürgen

Hallo,

so ganz habe ich das Problem noch nicht verstanden, evtl. kannst du es näher umschreiben.
Wenn du einen Member hast, der von aussen nicht geändert werden darf, wäre das doch der klassische Fall für ein Property, das nur einen getter besitzt.

Wenn das Programm den Wert nicht ändern kann, wer kann ihn dann setzen?
Mit nullable hat das eigentlich nichts zu tun. Wenn der Wert nur einmalig gesetzt werden darf, wärs am einfachsten wenn du im Setter prüfst ob du ihn schon mal gesetzt hast (mit einem vorbelegten Wert oder zur Not mit einem separaten bool Merker).
Wenn er schon mal gesetzt wurde, Exception werfen. Dann merkst du ob dein Programm den Wert zweimal setzt.

Hallo,

also ich hatte mir das etwa so vorgestellt:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            nullableTestClass test = new nullableTestClass();
            if (test.Wert == null)
            {
                Console.WriteLine("NULL");
            }
            else
            {
                Console.WriteLine(test.Wert);
            }
            test.Wert = true;
            Console.WriteLine(test.Wert);
            test.Wert = false;
            Console.WriteLine(test.Wert);
            Console.ReadKey();
        }
    }
    class nullableTestClass
    {
        private bool? wert;
        public bool? Wert
        {
            get
            {
                return wert;
            }
            set
            {
                if (wert == null)
                    wert = value;
            }
        }
    }
}

Solange 'Wert' NULL ist kann ihm ein Wert zugewiesen werden.
Hat jedoch eine Zuweisung stattgefunden, so kann dieser nicht mehr geändert werden.

Viele Grüße

Jürgen

Sieht doch gut aus. Wo ist das Problem?

Hallo Chilic,

meine Frage ist, ob dies eine übliche Vorgehensweise ist, oder ob ich mich in etwas verrenne was so niemand anwenden würde?

Viele Grüße

Jürgen

Hallo,

das kann man schon so machen.
Eleganter wäre es allerdings, wenn du den Wert im Konstruktor übergibst, dann reicht ein einfacher getter aus.
Das geht natürlich nur, wenn dein Anwendungsfall das erlaubt, d.h. wenn du bei der Objekterzeugung den Wert schon kennst.

Hallo bigeddie,

ob die Lösung gut ist, hängt, wie Sarc schon andeutet, von den Umständen ab. Sollten die Daten schon zum Konstruktionszeitpunkt bekannt sind, sollte man Sarcs Vorschlag verwenden. Vor allem, weil man dann die Felder als readonly deklarieren kann. Und weil man dann kein Nullable und keinen Setter braucht.

Wenn die Werte erst später bekannt sind, hängt es auch wieder von den Umständen ab.

Nullable braucht man überhaupt nur bei Werttypen.

Und ob man Null als (zusätzlichen) Wert braucht, hängt davon ab, ob der gesamte Wertebereich des Typ der Property verwendet wird. Zum Beispiel bei einem int, der in der konkreten Situation nur positive Zahlen aufnehmen soll, würde es reichen, ihn auf -1 zu initialisieren und ihn nur zu setzen, wenn er noch -1 ist. Wenn die Zahlen sie echt positiv sind, könnte man sogar den Defaultwert 0 als Indikator verwenden. Möglicherweise kommt man überall mit dem Defaultwert hin und braucht Null gar nicht.

Ob man Null braucht hängt auch davon ab, ob der Benutzer der Klasse die Werte abfragt, bevor sie gesetzt sind. Mit Null hätte er dann ein universelles Erkennungsmerkmal und muss nicht auf möglicherweise verschiedene ungültige Wert abzufragen. Wenn man überall mit dem Defaultwert hinkäme, hätte man aber auch damit eine einheitliche Abfragemöglichkeit.

Mit Nullable hat man also ein generelleres Vorgehen. Auch wenn später noch weitere Properties hinzukommen, kann man die mit Nullable alle einheitlich realisieren, egal ob der gesamte Wertebereich der konkreten Properties ausgeschöpft wird oder nicht.

Wenn es allerdings viele Properties werden, die sowieso immer alle auf eine Rutsch gesetzt werden, wäre es unsinnig, wenn jede einzelne Property sich darum kümmern würde, ob sie bereits gesetzt ist. Hier könnte man ein Feld bzw. eine Property Frozen o.ä. in der Klasse ansiedeln, die angibt, ob das Objekt als ganzes gesetzt ist oder nicht.

Man kann das sicher noch weiterspinnen. Allerdings finde ich, dass sich die Antworten auf alle auftauchen Fragen recht straightforward ergeben.

herbivore