Esiste una strategia di progettazione specifica che può essere applicata per risolvere la maggior parte dei problemi di gallina e uova durante l'uso di oggetti immutabili?

La soluzione è di imbrogliare un po '. In particolare:

• Crea A, ma lascia il suo riferimento a B non inizializzato (poiché B non esiste ancora).

• Crea B, e fallo puntare su A.

• Aggiorna A per puntare a B. Non aggiornare A o B dopo questo.

Questo può essere fatto esplicitamente (esempio in 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 implicitamente (esempio in Haskell):

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

L'esempio di Haskell utilizza la valutazione pigra per ottenere l'illusione di valori immutabili reciprocamente dipendenti. I valori iniziano come:

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

a e b sono entrambi validi moduli head-normal in modo indipendente. Ogni contro può essere costruito senza aver bisogno del valore finale dell'altra variabile. Quando il thunk viene valutato, punta quindi allo stesso dato b punti a.

Quindi, se vuoi che due valori immutabili puntino l'un l'altro, devi aggiornare il primo dopo aver costruito il secondo o utilizzare un meccanismo di livello superiore per fare lo stesso.

Nel tuo esempio particolare, potrei esprimerlo in Haskell come:

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

Tuttavia, sto affrontando il problema. Immagino che in un approccio orientato agli oggetti, in cui un metodo setTemperature è collegato al risultato di ogni costruttore di Material , è necessario che i costruttori puntino l'uno sull'altro. Se i costruttori sono trattati come valori immutabili, puoi utilizzare l'approccio descritto sopra.

Nel tuo esempio, stai applicando una trasformazione a un oggetto, quindi utilizzerei qualcosa come un metodo ApplyTransform() che restituisce un BlockBase piuttosto che provare a cambiare l'oggetto corrente.

Ad esempio, per cambiare un IceBlock in un WaterBlock applicando un po 'di calore, chiamerei qualcosa come

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

e il metodo IceBlock.ApplyTemperature() sarebbe simile al seguente:

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

Un altro modo per spezzare il ciclo è separare le preoccupazioni di materiale e trasmutazione, in qualche linguaggio inventato:

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),
]);

Se intendi usare un linguaggio funzionale e vuoi realizzare i benefici dell'immutabilità, dovresti affrontare il problema pensando a questo. Stai tentando di definire un tipo di oggetto "ghiaccio" o "acqua" in grado di supportare un intervallo di temperature: per supportare l'immutabilità, dovrai creare un nuovo oggetto ogni volta che la temperatura cambia, il che è uno spreco. Quindi cerca di rendere i concetti di tipo blocco e temperatura più indipendenti. Non conosco Scala (è sulla mia lista di cose da imparare :-)), ma prendendo a prestito da Joey Adams Risposta in Haskell , suggerisco qualcosa del tipo:

data Material = Water | Ice

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

o forse:

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

(Nota: non ho provato a farlo, e il mio Haskell è un po 'arrugginito.) Ora, la logica di transizione è separata dal tipo di materiale, quindi non spreca più memoria, e (secondo me ) è un po 'più orientato dal punto di vista funzionale.