Si encuentras algún detalle que no comprendes puedes comentarlo y te ayudaremos lo mas rápido que podamos.
Solución:
Para información, el segundo enfoque se llama “inmutabilidad de paleta”.
Eric Lippert tiene una serie de entradas de blog sobre inmutabilidad que comienzan aquí. Todavía me estoy familiarizando con el CTP (C# 4.0), pero parece interesante qué parámetros opcionales/nombrados (para el .ctor) podrían hacer aquí (cuando se asignan a campos de solo lectura)…
[update: I’ve blogged on this here]
Para obtener información, probablemente no haría esos métodos virtual – probablemente no queramos que las subclases puedan hacer que no se pueda congelar. Si desea que puedan agregar código adicional, sugeriría algo como:
[public|protected] void Freeze()
if(!frozen)
frozen = true;
OnFrozen();
protected virtual void OnFrozen() // subclass can add code here.
Además, AOP (como PostSharp) podría ser una opción viable para agregar todas esas comprobaciones ThrowIfFrozen().
(Disculpas si he cambiado la terminología/los nombres de los métodos; SO no mantiene visible la publicación original al redactar las respuestas)
Otra opción sería crear algún tipo de clase Builder.
Por ejemplo, en Java (y C# y muchos otros lenguajes) String es inmutable. Si desea realizar múltiples operaciones para crear una cadena, use un StringBuilder. Esto es mutable, y luego, una vez que haya terminado, le devolverá el objeto String final. A partir de ahí es inmutable.
Podrías hacer algo similar para tus otras clases. Tienes tu Elemento inmutable y luego un ElementBuilder. Todo lo que haría el constructor sería almacenar las opciones que configuraste, luego, cuando lo finalizas, construye y devuelve el Elemento inmutable.
Es un poco más de código, pero creo que es más limpio que tener setters en una clase que se supone que es inmutable.
Después de mi incomodidad inicial por el hecho de que tenía que crear una nueva System.Drawing.Point en cada modificación, he abrazado completamente el concepto hace algunos años. De hecho, ahora creo cada campo como readonly de forma predeterminada y solo cámbielo para que sea mutable si hay una razón convincente, que sorprendentemente rara vez ocurre.
Sin embargo, no me importan mucho los problemas de subprocesos cruzados (rara vez uso código donde esto es relevante). Lo encuentro mucho, mucho mejor debido a la expresividad semántica. La inmutabilidad es el epítome mismo de una interfaz que es difícil de usar incorrectamente.