¿Cómo manejo los setters en campos inmutables?

Tengo una clase con dos readonly intcampos. Están expuestos como propiedades:

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

Sin embargo, eso significa que lo siguiente es un código perfectamente legal:

Thing iThoughtThisWasMutable = new Thing(1, 42);

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

Los errores que surgen al suponer que funcionarían seguramente serán insidiosos. Claro, el desarrollador equivocado debería haber leído los documentos. Pero eso no cambia el hecho de que ningún error de compilación o tiempo de ejecución le advirtió sobre el problema.

¿Cómo se debe Thingcambiar la clase para que los desarrolladores tengan menos probabilidades de cometer el error anterior?

¿Lanzar una excepción? ¿Usar un método getter en lugar de una propiedad?

¿Por qué legalizar ese código?
Saque el set { }si no hace nada.
Así es como define una propiedad pública de solo lectura:

public int Foo { get { return _foo; } }

Con C # 5 y antes, nos enfrentamos con dos opciones para campos inmutables expuestos a través de un captador:

1. Cree una variable de respaldo de solo lectura y devuélvala a través de un captador manual. Esta opción es segura (se debe eliminar explícitamente readonlypara destruir la inmutabilidad. Sin embargo, creó mucho código de placa de caldera).
2. Use una propiedad automática, con un setter privado. Esto crea un código más simple, pero es más fácil romper accidentalmente la inmutabilidad.

Sin embargo, con C # 6 (disponible en VS2015, que se lanzó ayer), ahora obtenemos lo mejor de ambos mundos: propiedades automáticas de solo lectura. Esto nos permite simplificar la clase del OP para:

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

Las líneas Foo = fooy Bar = barsolo son válidas en el constructor (que logra el requisito robusto de solo lectura) y el campo de respaldo está implícito, en lugar de tener que definirse explícitamente (lo que logra el código más simple).

Podrías deshacerte de los setters. No hacen nada, confundirán a los usuarios y generarán errores. Sin embargo, podría hacerlos privados y así deshacerse de las variables de respaldo, simplificando su código:

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

Dos soluciones

Simple:

No incluya setters como lo señaló David para objetos de solo lectura inmutables.

Alternativamente:

Permitir que los configuradores devuelvan un nuevo objeto inmutable, detallado en comparación con el anterior, pero proporciona un estado en el tiempo para cada objeto inicializado. Este diseño es una herramienta muy útil para la seguridad e inmutabilidad de subprocesos que se extiende sobre todos los lenguajes imperativos de OOP.

Pseudocódigo

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

fábrica pública estática

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