Jak obsługiwać seterów na niezmiennych polach?

Mam klasę z dwoma readonly intpolami. Są eksponowane jako właściwości:

public class Thing
{
    private readonly int _foo, _bar;

    /// <summary> I AM IMMUTABLE. </summary>
    public Thing(int foo, int bar)
    {
        _foo = foo;
        _bar = bar;
    }

    public int Foo { get { return _foo; } set { } }

    public int Bar { get { return _bar; } set { } }
}

Oznacza to jednak, że następujący kod jest całkowicie zgodny z prawem:

Thing iThoughtThisWasMutable = new Thing(1, 42);

iThoughtThisWasMutable.Foo = 99;  // <-- Poor, mistaken developer.
                                  //     He surely has bugs now. :-(

Błędy wynikające z założenia, że to zadziała, z pewnością będą podstępne. Jasne, błędny programista powinien przeczytać dokumenty. Ale to nie zmienia faktu, że żaden błąd kompilacji lub wykonania nie ostrzegł go o problemie.

Jak Thingzmienić klasę, aby deweloperzy nie popełnili powyższego błędu?

Rzuć wyjątek? Używasz metody gettera zamiast właściwości?

Dlaczego ten kodeks jest legalny?
Wyjmij, set { }jeśli nic nie robi.
Oto jak definiujesz własność publiczną tylko do odczytu:

public int Foo { get { return _foo; } }

W wersji C # 5 i wcześniejszych mieliśmy do czynienia z dwiema opcjami dla niezmiennych pól eksponowanych przez getter:

1. Utwórz zmienną bazową tylko do odczytu i zwróć ją za pomocą metody pobierającej ręcznie. Ta opcja jest bezpieczna (należy jawnie usunąć, readonlyaby zniszczyć niezmienność. Stworzyło to jednak mnóstwo kodu płyty kotłowej.
2. Użyj auto-właściwości z prywatnym ustawiaczem. Tworzy to prostszy kod, ale łatwiej jest przypadkowo złamać niezmienność.

Jednak w wersji C # 6 (dostępnej w wersji VS2015, która została wydana wczoraj), otrzymujemy to, co najlepsze z obu światów: właściwości automatyczne tylko do odczytu. To pozwala nam uprościć klasę OP w celu:

public class Thing
{
    /// <summary> I AM IMMUTABLE. </summary>
    public Thing(int foo, int bar)
    {
        Foo = foo;
        Bar = bar;
    }

    public int Foo { get; }
    public int Bar { get; }
}

Foo = fooI Bar = barlinie są ważne tylko w konstruktor (co osiąga się niezawodne wymagania tylko do odczytu), i pole podłoża zakłada się, zamiast być wyraźnie określone (który uzyskuje się prostszą kodu).

Możesz po prostu pozbyć się seterów. Nic nie robią, wprowadzą użytkowników w błąd i doprowadzą do błędów. Możesz jednak zamiast tego ustawić je jako prywatne i pozbyć się zmiennych pomocniczych, upraszczając kod:

public class Thing
{
    public Thing(int foo, int bar)
    {
        Foo = foo;
        Bar = bar;
    }

    public int Foo { get; private set; }

    public int Bar { get; private set; }
}

Dwa rozwiązania.

Prosty:

Nie dołączaj seterów, jak zauważył David dla niezmiennych obiektów tylko do odczytu.

Alternatywnie:

Zezwól ustawiającym na zwrócenie nowego niezmiennego obiektu, szczegółowego w porównaniu z poprzednim, ale zapewnia stan w czasie dla każdego zainicjowanego obiektu. Ta konstrukcja jest bardzo przydatnym narzędziem do zapewnienia bezpieczeństwa i niezmienności wątków, które obejmuje wszystkie niezbędne języki OOP.

Pseudo kod

public class Thing
{

{readonly vars}

    public Thing(int foo, int bar)
    {
        _foo = foo;
        _bar = bar;
    }

    public Thing withFoo(int foo) {
        return new Thing(foo, getBar());
    }

    public Thing withBar(int bar) {
        return new Thing(getFoo(), bar)
    }

    etc...
}

publiczna fabryka statyczna

public class Thing
{

{readonly vars}

    private Thing(int foo, int bar)
    {
        _foo = foo;
        _bar = bar;
    }

    public static with(int foo, int bar) {
        return new Thing(foo, bar)
    }

    public Thing withFoo(int foo) {
        return new Thing(foo, getBar());
    }

    public Thing withBar(int bar) {
        return new Thing(getFoo(), bar)
    }

    etc...
}