Is there a specific design strategy that can be applied to solve most chicken-and-egg problems while using immutable objects?

Question

Coming from a OOP background (Java), I'm learning Scala on my own. While I can readily see the advantages of using immutable objects individually, I'm having a hard time seeing how one can design a whole application like that. I'll give an example:

Say I have objects that represents "materials" and their properties (I'm designing a game, so I actually really have that problem), like water and ice. I would have a "manager" that owns all such materials instances. One property would be the freezing and melting point, and what the material freezes or melts to.

[EDIT] All material instances are "singleton", kind of like a Java Enum.

I want "water" to say it freezes to "ice" at 0C, and "ice" to say it melts to "water" at 1C. But if water and ice are immutable, they cannot get a reference to each other as constructor parameters, because one of them has to be created first, and that one could not get a reference to the not-yet-existing other as constructor parameter. I could solve this by giving them both a reference to the manager so that they can query it to find the other material instance they need every time they are being asked for their freezing/melting properties, but then I get the same problem between the manager and the materials, that they need a reference to each other, but it can only be provided in the constructor for one of them, so either the manager or the material cannot be immutable.

Is their just no way around this problem, or do I need to use "functional" programming techniques, or some other pattern to solve it?

Answer 1

The solution is to cheat a little bit. Specifically:

• Create A, but leave its reference to B uninitialized (as B doesn't exist yet).

• Create B, and have it point to A.

• Update A to point to B. Do not update either A or B after this.

This can either be done explicitly (example 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;
}

or implicitly (example in Haskell):

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

The Haskell example uses lazy evaluation to achieve the illusion of mutually dependent immutable values. The values start out as:

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

a and b are both valid head-normal forms independently. Each cons can be constructed without needing the final value of the other variable. When the thunk is evaluated, it will then point to the same data b points to.

Thus, if you want two immutable values to point to each other, you either have to update the first after constructing the second, or use a higher-level mechanism to do the same.

---

In your particular example, I might express it in Haskell as:

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

However, I'm side-stepping the issue. I'd imagine that in an object-oriented approach, where a setTemperature method is attached to the result of each Material constructor, you would have to have the constructors point to each other. If the constructors are treated as immutable values, you can use the approach outlined above.

Answer 2

In your example, you're applying a transformation to an object so I would use something like an ApplyTransform() method that returns a BlockBase rather than trying to change the current object.

For example, to change an IceBlock to a WaterBlock by applying some heat, I would call something like

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

and the IceBlock.ApplyTemperature() method would look something like this:

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

Answer 3

Another way of breaking the cycle is to separate the concerns of material and transmutation, in some made up language:

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

Answer 4

If you're going to use a functional language, and you want to realize the benefits of immutability, then you should approach the problem with that in mind. You're attempting to define an object type "ice" or "water" that can support a range of temperatures - in order to support immutability, you'd then need to create a new object every time the temperature changes, which is wasteful. So try to make the concepts of block-type and temperature more independent. I don't know Scala (it's on my to-learn list :-) ), but borrowing from Joey Adams Answer in Haskell, I suggest something like:

data Material = Water | Ice

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

or maybe:

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

(Note: I haven't tried to run this, and my Haskell's a little rusty.) Now, the transition logic is separated from the material type, so it doesn't waste as much memory, and (in my opinion) it's quite a bit more functionally oriented.