Как мне обращаться с сеттерами на неизменяемых полях?

У меня есть класс с двумя readonly intполями. Они выставлены как свойства:

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 { } }
}

Тем не менее, это означает, что следующее является совершенно законным кодом:

Thing iThoughtThisWasMutable = new Thing(1, 42);

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

Ошибки, возникающие при предположении, что это сработает, наверняка будут коварными. Несомненно, ошибочный разработчик должен был прочитать документы. Но это не меняет того факта, что ни одна ошибка компиляции или времени выполнения не предупредила его о проблеме.

Как следует Thingизменить класс, чтобы разработчики с меньшей вероятностью допустили вышеуказанную ошибку?

Бросить исключение? Использовать метод получения вместо свойства?

Зачем делать этот код легальным?
Вынь, set { }если ничего не получится .
Вот как вы определяете публичное свойство только для чтения:

public int Foo { get { return _foo; } }

В C # 5 и ранее мы столкнулись с двумя вариантами неизменяемых полей, доступных через геттер:

1. Создайте резервную копию только для чтения и верните ее через ручной метод получения. Эта опция безопасна (нужно явно удалить, readonlyчтобы уничтожить неизменность. Хотя она создала много кода-шаблона).
2. Используйте авто-свойство с частным сеттером. Это создает более простой код, но легче случайно сломать неизменность.

Хотя с C # 6 (доступно в VS2015, который был выпущен вчера), мы теперь получаем лучшее из обоих миров: автоматические свойства только для чтения. Это позволяет нам упростить класс ОП:

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 = fooИ Bar = barлинии действительны только в конструкторе (который достигает требования к надежным только для чтения) , а поле подложки подразумеваются, вместо того , чтобы быть явно определенно (который достигает более простой код).

Вы могли бы просто избавиться от сеттеров. Они ничего не делают, они сбивают с толку пользователей и приводят к ошибкам. Однако вместо этого вы можете сделать их закрытыми и, таким образом, избавиться от резервных переменных, упрощая ваш код:

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; }
}

Два решения.

Просто:

Не включайте сеттеры, как отметил Дэвид, для неизменяемых объектов только для чтения.

В качестве альтернативы:

Разрешить сеттерам возвращать новый неизменный объект, более подробный по сравнению с первым, но предоставляющий состояние с течением времени для каждого инициализированного объекта. Этот дизайн - очень полезный инструмент для безопасности и неизменяемости потоков, который распространяется на все обязательные языки ООП.

ПСЕВДОКОД

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...
}

публичная статическая фабрика

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...
}