Table builder pattern

Question

Trying to combine functional style (immutable objects) and flexibility of property setters. For the sake of example, let’s say we have a soil types table with two attributes: Color and Name. I am looking for a way to alternate Names, but not Color. Here is how I solved it:

        // retrieving: all objects are immutable
        SoilTypes types = SoilTypes.Default;
        ISoilType clay1 = types.Clay;
        ISoilType clay2 = types[3];

        // derive an alternated immutable copy
        SoilTypes altTypes = types
            .With(tt =>
            {
                // tt.SensitiveFines.Color is still read only
                tt.SensitiveFines.Name = "Very sensitive fines!";
                tt[2].Name = "Purely Organic soil!";
            });

        // retrieving: everything is immutable
        ISoilType sensitiveFines = altTypes.SensitiveFines;

Where this interface is immutable:

public interface ISoilType
{
    Color Color { get; }
    string Name { get; }
}

And this class is mutable:

public class SoilType : ISoilType
{
    public static implicit operator SoilType((Color Color, string Name) tuple) =>
         new SoilType(tuple.Color, tuple.Name);

    internal SoilType(ISoilType source)
        : this(source.Color, source.Name)
    {
    }

    internal SoilType(Color color, string name)
    {
        Color = color;
        Name = name;
    }

    public Color Color { get; }
    public string Name { get; set; }
}

And this non-generic class is immutable:

public class SoilTypes : SoilTypes<ISoilType>
{
    public static SoilTypes Default = new SoilTypes(
        (White, "Undefined"),
        (Red, "Sensitive Fines"),
        (Green, "Organic Soil"),
        (Blue, "Clay"),
        (Orange, "Silty Clay"));

    public SoilTypes(params SoilType[] types)
        : base(types)
    {
    }

    public SoilTypes With(Action<SoilTypes<SoilType>> update)
    {
        var copy = this
            .Select(t => new SoilType(t))
            .ToArray();

        update(new SoilTypes<SoilType>(copy));
        return new SoilTypes(copy);
    }
}

while this generic base used in both situations:

public class SoilTypes<TType> : ReadOnlyCollection<TType>
    where TType : ISoilType
{
    internal SoilTypes(TType[] types)
        : base(types)
    {
    }

    public TType Undefined => this[0];
    public TType SensitiveFines => this[1];
    public TType OrganicSoil => this[2];
    public TType Clay => this[3];
    public TType SiltyClay => this[4];
}

Answer 1

I'm afraid this is not fully immutable becasue I am able to change the Name with a simple cast:

altTypes.Dump();
((SoilType)altTypes.SensitiveFines).Name = "foo";
altTypes.Dump();

The underlying data type is still SoilType so the interface does not protect the data from being overriden.

Consider a user that writes a function like this one because he doesn't like interfaces :-)

public static void foo(SoilType bar)
{
    bar.Name = "new name";
}

and calls it

foo((SoilType)altTypes.SensitiveFines);
altTypes.Dump();

Name changed. Unfortunatelly I have no idea how to prevent it yet.

Answer 2

Guess, I must start with a disclaimer again -- after multiple rereadings, still unsure what exactly the code tries to achieve.

The big confusion (of mine)

There's one thing I really don't like about SoilTypes<TType>, namely the ad hoc-ish mapping to collection entries by index. The consumer of the class will have to know that implementation detail, right?

Don't have a C# compiler in front of me at the moment so I could play with things.

Is there a way to keep public static SoilTypes Default = ... and the public TType Undefined => this[0]; as close together as possible (meaning, in the same class)? Not sure if it is achievable.

On naming the lambda parameters

As a minor thing, I'd note that tt is a bit confusing. Bet, you know we can write (@type => ....

Readability

I know that .With(...) fluent syntax is very well known, I haven't really seen that working with a collection (non-scalar) object, though. In other words, while you're not inventing anything new with this idiom, it's still a bit unintuitive to me. Please disregard this comment if you find it a subjective thing. :)

P.S. Good question, just like many others that you post on CR!

Answer 3

I have defined mutable/immutable dichotomy in a cleaner way according @t3chb0t answer:

public class SoilType 
{
    internal SoilType(Color color, string name)
    {
        Color = color;
        Name = name;
    }

    public Color Color { get; }
    public string Name { get; protected set; }

    internal AltSoilType Mutable =>
        new AltSoilType(this);
}

And

public class AltSoilType : SoilType
{
    internal AltSoilType(SoilType source)
        : base(source.Color, source.Name)  
    {
    }

    public new string Name 
    {
        get { return base.Name; }
        set { base.Name = value; }
    }

    internal SoilType Immutable => 
        new SoilType(Color, Name);
}