Esiste una strategia di progettazione specifica che può essere applicata per risolvere la maggior parte dei problemi di galline e uova utilizzando oggetti immutabili?

Provenendo da un background OOP (Java), sto imparando Scala da solo. Mentre posso facilmente vedere i vantaggi dell'utilizzo di oggetti immutabili singolarmente, sto facendo fatica a vedere come si può progettare un'intera applicazione del genere. Faccio un esempio:

Supponiamo di avere oggetti che rappresentano i "materiali" e le loro proprietà (sto progettando un gioco, quindi ho davvero quel problema), come l'acqua e il ghiaccio. Avrei un "manager" che possiede tutte queste istanze di materiali. Una proprietà sarebbe il punto di congelamento e fusione e ciò a cui il materiale si congela o si scioglie.

[EDIT] Tutte le istanze materiali sono "singleton", un po 'come un Enum Java.

Voglio "acqua" per dire che si congela a "ghiaccio" a 0 ° C, e "ghiaccio" per dire che si scioglie in "acqua" a 1 ° C. Ma se l'acqua e il ghiaccio sono immutabili, non possono ottenere un riferimento reciproco come parametri del costruttore, perché uno di essi deve essere creato per primo e che non si può ottenere un riferimento all'altro non ancora esistente come parametro del costruttore. Potrei risolvere questo dando a entrambi un riferimento al gestore in modo che possano interrogarlo per trovare l'altra istanza materiale di cui hanno bisogno ogni volta che viene chiesto loro le proprietà di congelamento / fusione, ma poi ottengo lo stesso problema tra il gestore e i materiali, di cui hanno bisogno di un riferimento reciproco, ma possono essere forniti nel costruttore solo per uno di essi, quindi il manager o il materiale non possono essere immutabili.

Non è proprio il modo per aggirare questo problema o devo usare tecniche di programmazione "funzionali" o qualche altro modello per risolverlo?

La soluzione è imbrogliare un po '. In particolare:

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

• Crea B e fai puntare ad A.

• Aggiorna A per indicare B. Non aggiornare successivamente A o B.

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 una valutazione pigra per ottenere l'illusione di valori immutabili reciprocamente dipendenti. I valori iniziano come:

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

ae bsono entrambi forme normali normali valide indipendentemente. Ogni contro può essere costruito senza bisogno del valore finale dell'altra variabile. Quando viene valutato, il thunk indicherà gli stessi datib punta.

Pertanto, se si desidera che due valori immutabili siano puntati l'uno verso l'altro, è necessario aggiornare il primo dopo aver costruito il secondo oppure 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 setTemperaturemetodo è attaccato al risultato di ciascun Materialcostruttore, dovresti fare in modo che i costruttori puntino l'uno verso l'altro. Se i costruttori sono trattati come valori immutabili, è possibile utilizzare l'approccio descritto sopra.

Nel tuo esempio, stai applicando una trasformazione a un oggetto in modo da utilizzare qualcosa come un ApplyTransform()metodo che restituisce aBlockBase anziché tentare di modificare l'oggetto corrente.

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

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

e il IceBlock.ApplyTemperature()metodo sarebbe simile a questo:

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

Un altro modo per interrompere il ciclo è quello di separare le preoccupazioni di materiale e trasmutazione, in un 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 hai intenzione di usare un linguaggio funzionale e vuoi realizzare i benefici dell'immutabilità, allora dovresti affrontare il problema con questo in mente. Stai tentando di definire un tipo di oggetto "ghiaccio" o "acqua" in grado di supportare un intervallo di temperature - per supportare l'immutabilità, dovrai quindi creare un nuovo oggetto ogni volta che la temperatura cambia, il che è dispendioso. Quindi cerca di rendere i concetti di tipo di blocco e temperatura più indipendenti. Non conosco Scala (è sulla mia lista di apprendimenti :-)), ma prendendo in 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 eseguire questo, e il mio Haskell è un po 'arrugginito.) Ora, la logica di transizione è separata dal tipo di materiale, quindi non spreca tanta memoria e (secondo me) è abbastanza un po 'più orientato alla funzionalità.