不変オブジェクトを使用しながら、鶏と卵のほとんどの問題を解決するために適用できる特定の設計戦略はありますか？

OOPのバックグラウンド（Java）から来て、私は自分でScalaを学んでいます。不変オブジェクトを個別に使用することの利点はすぐにわかりますが、そのようなアプリケーション全体をどのように設計できるかを見るのは大変です。例を挙げます。

「マテリアル」とそれらのプロパティを表すオブジェクト（ゲームを設計しているので、実際にその問題を抱えている）があり、たとえば水や氷があるとします。このようなすべてのマテリアルインスタンスを所有する「マネージャー」がいます。1つの特性は、凝固点と融点、および材料が凍結または融解するものです。

[編集]すべてのマテリアルインスタンスは「シングルトン」で、Java Enumのようなものです。

「水」は0℃で「氷」に凍結し、「氷」は1℃で「水」に融解すると言います。しかし、水と氷が不変である場合、それらの1つを最初に作成する必要があり、コンストラクターパラメーターとしてまだ存在しない他のものへの参照を取得できなかったため、コンストラクターパラメーターとして相互参照を取得できません。両方のマネージャーへの参照を提供することでこれを解決することができますので、彼らは凍結/融解特性を求められるたびに必要な他の材料インスタンスを見つけるためにクエリすることができますが、マネージャー間で同じ問題が発生しますそして、それらはお互いへの参照を必要としますが、それらのうちの1つのコンストラクターでのみ提供できるため、マネージャーまたはマテリアルは不変にできません。

彼らはこの問題を回避する方法がないのですか、それとも「機能的な」プログラミング技術、またはそれを解決するための他のパタ​​ーンを使用する必要がありますか？

解決策は少しチートすることです。具体的には：

• Aを作成しますが、Bへの参照は初期化されません（Bはまだ存在しないため）。

• Bを作成し、Aを指すようにします。

• Bを指すようにAを更新します。この後、AもBも更新しないでください。

これは明示的に行うことができます（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;
}

または暗黙的に（Haskellの例）：

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

Haskellの例では、遅延評価を使用して、相互に依存する不変の値の錯覚を実現しています。値は次のように始まります。

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

aそしてb両方とも有効なヘッド正規形独立。各コンスは、他の変数の最終値を必要とせずに構築できます。サンクが評価されると、サンクは同じデータbポイントを指します。

したがって、2つの不変の値が相互に指し示すようにする場合は、2番目の値を作成した後に最初の値を更新するか、より高いレベルのメカニズムを使用して同じことを行う必要があります。

あなたの特定の例では、Haskellで次のように表現できます。

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

しかし、私は問題を回避しています。setTemperatureメソッドが各Materialコンストラクターの結果にアタッチされるオブジェクト指向のアプローチでは、コンストラクターが互いにポイントする必要があると思います。コンストラクターが不変値として扱われる場合は、上記で概説したアプローチを使用できます。

この例では、オブジェクトに変換を適用しているため、現在のオブジェクトを変更しようとApplyTransform()するのBlockBaseではなく、aを返すメソッドのようなものを使用します。

たとえば、いくらかの熱を加えることによってIceBlockをWaterBlockに変更するには、次のように呼び出します

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

そしてIceBlock.ApplyTemperature()この方法は、次のようになります。

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

サイクルを壊す別の方法は、いくつかの構成言語で、物質と変換の懸念を分離することです：

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

関数型言語を使用し、不変性の利点を実現したい場合は、それを念頭に置いて問題に取り組む必要があります。さまざまな温度をサポートできるオブジェクトタイプ「氷」または「水」を定義しようとしています。不変性をサポートするには、温度が変化するたびに新しいオブジェクトを作成する必要があり、無駄です。したがって、ブロックタイプと温度の概念をより独立させてください。私はScalaを知りません（私の学習リストにあります:-)）、HaskellのJoey Adams Answerを借りて、次のようなものを提案します：

data Material = Water | Ice

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

または多分：

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

（注：私はこれを実行しようとしませんでしたが、私のHaskellは少し錆びています。）今、遷移ロジックはマテリアルタイプから分離されているので、それほど多くのメモリを無駄にしません（そして、私の意見では）もう少し機能指向です。