¿Existe una estrategia de diseño específica que pueda aplicarse para resolver la mayoría de los problemas de huevo y gallina mientras se usan objetos inmutables?

Viniendo de un fondo OOP (Java), estoy aprendiendo Scala por mi cuenta. Si bien puedo ver fácilmente las ventajas de usar objetos inmutables individualmente, me cuesta ver cómo se puede diseñar una aplicación completa como esa. Daré un ejemplo:

Digamos que tengo objetos que representan "materiales" y sus propiedades (estoy diseñando un juego, así que realmente tengo ese problema), como el agua y el hielo. Tendría un "gerente" que posee todas esas instancias de materiales. Una propiedad sería el punto de congelación y fusión, y a qué se congela o derrite el material.

[EDITAR] Todas las instancias materiales son "singleton", algo así como una enumeración de Java.

Quiero "agua" para decir que se congela a "hielo" a 0 ° C, y "hielo" para decir que se derrite a "agua" a 1 ° C. Pero si el agua y el hielo son inmutables, no pueden obtener una referencia el uno al otro como parámetros del constructor, porque uno de ellos debe crearse primero, y ese no podría obtener una referencia al otro que aún no existe como parámetro del constructor. Podría resolver esto dándoles a ambos una referencia al gerente para que puedan consultarlo para encontrar la otra instancia material que necesitan cada vez que se les solicite sus propiedades de congelación / fusión, pero luego obtengo el mismo problema entre el gerente y los materiales, que necesitan una referencia entre sí, pero solo se puede proporcionar en el constructor de uno de ellos, por lo que el administrador o el material no pueden ser inmutables.

¿Simplemente no hay forma de evitar este problema, o necesito usar técnicas de programación "funcionales", o algún otro patrón para resolverlo?

La solución es hacer trampa un poco. Específicamente:

• Cree A, pero deje su referencia a B sin inicializar (ya que B aún no existe).

• Crea B y haz que apunte a A.

• Actualice A para que apunte a B. No actualice A ni B después de esto.

Esto se puede hacer explícitamente (ejemplo en C ++):

struct List {
    int n;
    List *next;

    List(int n, List *next)
        : n(n), next(next);
};

// Return a list containing [0,1,0,1,...].
List *binary(void)
{
    List *a = new List(0, NULL);
    List *b = new List(1, a);
    a->next = b; // Evil, but necessary.
    return a;
}

o implícitamente (ejemplo en Haskell):

binary :: [Int]
binary = a where
    a = 0 : b
    b = 1 : a

El ejemplo de Haskell utiliza una evaluación perezosa para lograr la ilusión de valores inmutables mutuamente dependientes. Los valores comienzan como:

a = 0 : <thunk>
b = 1 : a

ay bson formas válidas de cabeza normal independientemente. Cada contra puede construirse sin necesitar el valor final de la otra variable. Cuando se evalúa el thunk, apuntará a los mismos bpuntos de datos .

Por lo tanto, si desea que dos valores inmutables se apunten entre sí, debe actualizar el primero después de construir el segundo o utilizar un mecanismo de nivel superior para hacer lo mismo.

En su ejemplo particular, podría expresarlo en Haskell como:

data Material = Water {temperature :: Double}
              | Ice   {temperature :: Double}

setTemperature :: Double -> Material -> Material
setTemperature newTemp (Water _) | newTemp <= 0.0 = Ice newTemp
                                 | otherwise      = Water newTemp
setTemperature newTemp (Ice _)   | newTemp >= 1.0 = Water newTemp
                                 | otherwise      = Ice newTemp

Sin embargo, estoy esquivando el problema. Me imagino que en un enfoque orientado a objetos, donde setTemperaturese adjunta un método al resultado de cada Materialconstructor, tendría que hacer que los constructores se apuntaran entre sí. Si los constructores se tratan como valores inmutables, puede utilizar el enfoque descrito anteriormente.

En su ejemplo, está aplicando una transformación a un objeto, por lo que usaría algo como un ApplyTransform()método que devuelve un en BlockBaselugar de intentar cambiar el objeto actual.

Por ejemplo, para cambiar un IceBlock a un WaterBlock aplicando algo de calor, llamaría algo así como

BlockBase currentBlock = new IceBlock();
currentBlock = currentBlock.ApplyTemperature(1); 
// currentBlock is now a WaterBlock 

y el IceBlock.ApplyTemperature()método se vería así:

public class IceBlock() : BlockBase
{
    public BlockBase ApplyTemperature(int temp)
    {
        return (temp > 0 ? new WaterBlock((BlockBase)this) : this);
    }
}

Otra forma de romper el ciclo es separar las preocupaciones del material y la transmutación, en un lenguaje inventado:

water = new Block("water");
ice = new Block("ice");

transitions = new Transitions([
    new transitions.temperature.Below(0.0, water, ice),
    new transitions.temperature.Above(0.0, ice, water),
]);

Si va a usar un lenguaje funcional, y quiere darse cuenta de los beneficios de la inmutabilidad, entonces debe abordar el problema con eso en mente. Está intentando definir un tipo de objeto "hielo" o "agua" que pueda soportar un rango de temperaturas; para soportar la inmutabilidad, entonces necesitaría crear un nuevo objeto cada vez que cambie la temperatura, lo cual es un desperdicio. Así que trate de hacer que los conceptos de tipo de bloque y temperatura sean más independientes. No sé Scala (está en mi lista de aprendizaje :-)), pero tomando prestado de Joey Adams Answer en Haskell , sugiero algo como:

data Material = Water | Ice

blockForTemperature :: Double -> Material
blockForTemperature x = 
  if x < 0 then Ice else Water

o tal vez:

transitionForTemperature :: Material -> Double -> Material
transitionForTemperature oldMaterial newTemp = 
  case (oldMaterial, newTemp) of
    (Ice, _) | newTemp > 0 -> Water
    (Water, _) | newTemp <= 0 -> Ice

(Nota: no he intentado ejecutar esto, y mi Haskell está un poco oxidado). Ahora, la lógica de transición está separada del tipo de material, por lo que no desperdicia tanta memoria y (en mi opinión) es bastante un poco más funcionalmente orientado.