Diseño de construcción de clase inmutable

Question

De modo que todos nos damos cuenta de los beneficios de los tipos inmutables, particularmente en escenarios multiproceso. (O al menos todos deberíamos darnos cuenta, ver por ejemplo System.String.)

Sin embargo, lo que no he visto es mucha discusión para creando instancias inmutables, específicamente las pautas de diseño.

Por ejemplo, supongamos que queremos tener la siguiente clase inmutable:

class ParagraphStyle { 
    public TextAlignment Alignment {get;} 
    public float FirstLineHeadIndent {get;} 
    // ... 
} 

El enfoque más común que he visto es tener "pares" mutables/inmutables de tipos, por ejemplo los tipos mutables List<T> e inmutables ReadOnlyCollection<T> o los tipos mutables StringBuilder e inmutables String.

Para imitar este patrón existente requeriría la introducción de algún tipo de "mutable" ParagraphStyle tipo que "duplicados" los miembros (para proporcionar fijadores), y luego proporcionar un constructor ParagraphStyle que acepta el tipo mutable como un argumento

// Option 1: 
class ParagraphStyleCreator { 
    public TextAlignment {get; set;} 
    public float FirstLineIndent {get; set;} 
    // ... 
} 

class ParagraphStyle { 
    // ... as before... 
    public ParagraphStyle (ParagraphStyleCreator value) {...} 
} 

// Usage: 
var paragraphStyle = new ParagraphStyle (new ParagraphStyleCreator { 
    TextAlignment = ..., 
    FirstLineIndent = ..., 
}); 

Por lo tanto, esto funciona, admite la finalización de código dentro del IDE, y hace las cosas razonablemente obvias sobre cómo construir cosas ... pero parece bastante duplicativo.

¿Hay una manera mejor?

Por ejemplo, C# tipos anónimos son inmutables, y permitir el uso de fijadores "normales" de propiedad de inicialización:

var anonymousTypeInstance = new { 
    Foo = "string", 
    Bar = 42; 
}; 
anonymousTypeInstance.Foo = "another-value"; // compiler error 

Por desgracia, el camino más cercano para duplicar esta semántica en C# es el uso de parámetros del constructor:

// Option 2: 
class ParagraphStyle { 
    public ParagraphStyle (TextAlignment alignment, float firstLineHeadIndent, 
      /* ... */) {...} 
} 

Pero esto no se "escala" bien; si su tipo tiene, p. 15 propiedades, un constructor con 15 parámetros es cualquier cosa menos amigable, y proporcionar sobrecargas "útiles" para las 15 propiedades es una receta para una pesadilla. Estoy rechazando esto directamente.

Si tratamos de imitar los tipos anónimos, parece que podríamos usar "set-una vez" propiedades de tipo "inmutable", y por lo tanto dejar caer la "mutable" variante:

// Option 3: 
class ParagraphStyle { 
    bool alignmentSet; 
    TextAlignment alignment; 

    public TextAlignment Alignment { 
     get {return alignment;} 
     set { 
      if (alignmentSet) throw new InvalidOperationException(); 
      alignment = value; 
      alignmentSet = true; 
     } 
    } 
    // ... 
} 

El problema con esto es que no es obvio que las propiedades se puedan establecer solo una vez (el compilador ciertamente no se quejará), y la inicialización no es segura para subprocesos. Por lo tanto, resulta tentador agregar un método Commit() para que el objeto sepa que el desarrollador finalizó la configuración de las propiedades (lo que provoca que todas las propiedades que no se hayan configurado previamente arrojen si se invoca su definidor), pero esto parece ser una manera de empeorar las cosas, no mejor.

¿Hay un mejor diseño que la división de clase mutable/inmutable? ¿O estoy condenado a lidiar con la duplicación de miembros?

Answer 1

En un par de proyectos estaba usando un enfoque fluido. Es decir. la mayoría de las propiedades genéricas (por ejemplo, nombre, ubicación, título) se definen a través de ctor, mientras que otras se actualizan con métodos de Set que devuelven una nueva instancia inmutable.

class ParagraphStyle { 
    public TextAlignment Alignment {get; private set;} 
    public float FirstLineHeadIndent {get; private set;} 
    // ... 
    public ParagraphStyle WithAlignment(TextAlignment ta) { 
     var newStyle = (ParagraphStyle)MemberwiseClone(); 
     newStyle.TextAlignment = ta; 
    } 
    // ... 
} 

MemberwiseClone está bien aquí tan pronto nuestra clase sea realmente profundamente inmutable.