17

For various reasons I'd like to start using more immutable types in designs. At the moment, I'm working with a project which has an existing class like this:

public class IssueRecord
{
    // The real class has more readable names :)
    public string Foo { get; set; }
    public string Bar { get; set; }
    public int Baz { get; set; }
    public string Prop { get; set; }
    public string Prop2 { get; set; }
    public string Prop3 { get; set; }
    public string Prop4 { get; set; }
    public string Prop5 { get; set; }
    public string Prop6 { get; set; }
    public string Prop7 { get; set; } 
    public string Prop8 { get; set; } 
    public string Prop9 { get; set; }
    public string PropA { get; set; }
}

This class represents some on-disk format which really does have this many properties, so refactoring it into smaller bits is pretty much out of the question at this point.

Does this mean that the constructor on this class really needs to have 13 parameters in an immutable design? If not, what steps might I take to reduce the number of parameters accepted in the constructor if I were to make this design immutable?

Billy ONeal
  • 104,103
  • 58
  • 317
  • 552
  • Does something external to the class need to set the values, or can the class itself set the values? If the class can do it, then you can have a parameterless constructor. – Bob Horn Sep 06 '12 at 01:01
  • 1
    See: http://stackoverflow.com/questions/355172/how-to-design-an-immutable-object-with-complex-initialization?rq=1 – aquinas Sep 06 '12 at 01:04
  • How are you initializing these properties now? – Reed Copsey Sep 06 '12 at 01:09
  • 1
    See also: http://stackoverflow.com/questions/2848938/building-big-immutable-objects-without-using-constructors-having-long-parameter – Lukasz Madon Sep 06 '12 at 01:13

6 Answers6

14

To decrease number of arguments you can group them into sensible sets, but to have truly immutable object you have to initialize it in constructor/factory method.

Some variation is to create "builder" class that you can configure with fluent interface and than request final object. This would make sense if you actually planning to create many of such objects in different places of the code, otherwise many arguments in one single place maybe acceptable tradeoff.

var immutable = new MyImmutableObjectBuilder()
  .SetProp1(1)
  .SetProp2(2)
  .Build();
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
13

Does this mean that the constructor on this class really needs to have 13 parameters in an immutable design?

In general, yes. An immutable type with 13 properties will require some means of initializing all of those values.

If they are not all used, or if some properties can be determined based on the other properties, then you can perhaps have one or more overloaded constructors with fewer parameters. However, a constructor (whether or not the type is immutable) really should fully initialize the data for the type in a way that the type is logically "correct" and "complete."

This class represents some on-disk format which really does have this many properties, so refactoring it into smaller bits is pretty much out of the question at this point.

If the "on-disk format" is something that's being determined at runtime, you could potentially have a factory method or constructor which takes the initialization data (ie: the filename? etc) and builds the fully-initialized type for you.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
3

Perhaps keep your current class as it is, providing sensible defaults if possible and rename to IssueRecordOptions. Use this as a single initializing parameter to your immutable IssueRecord.

spender
  • 117,338
  • 33
  • 229
  • 351
  • This is a good option if the immutability requirement is only needed for a portion of the system. You're still dealing with mutable types, however, as you then have to mutate the original "Options" type. – Reed Copsey Sep 06 '12 at 01:08
3

You could use a combination of named and optional arguments in your constructor. If the values are always different, then yes, you're stuck with an insane constructor.

Netfangled
  • 2,071
  • 1
  • 18
  • 28
2

You could make a struct, but then you would still have to declare the struct. But there are always arrays and such. If they are all the same data type you can group them in several ways, such as an array, list or string. It does appear that you are right though, all of your immutable types must go through the constructor in some way, weather through 13 parameters, or through a struct, array, list, etc...

Carsen Daniel Yates
  • 1,962
  • 1
  • 11
  • 16
  • Oh, I just realized that most of them are strings, so I was right to say to use an array. – Carsen Daniel Yates Sep 06 '12 at 00:59
  • 2
    An array really doesn't work because it destroys the semantic meaning of the parameters in the struct. Someone using the class would have to remember that the 5th element in the array meant "Details" or something like that which is worse than just leaving the class mutable. – Billy ONeal Sep 06 '12 at 01:00
  • Right, then a struct is your only other real option. Plus if I am correct, in C#, a struct can use defaults, which could be useful in your situation. – Carsen Daniel Yates Sep 06 '12 at 01:01
  • 3
    A struct won't really help - if you were to make an immutable struct, you'd still need a constructor to initialize the data. (That being said, this violates just about every rule for when to choose a struct (>16 bytes, contains reference types, doesn't represent a single logical value, etc), so a class is almost definitely more appropriate here...) – Reed Copsey Sep 06 '12 at 01:11
  • I wasn't saying that he should use a struct instead, but he should pack the parameters into a struct. – Carsen Daniel Yates Sep 06 '12 at 02:36
  • 1
    @ReedCopsey: A struct with exposed fields is the perfect thing to use here. Structs which modify `this` outside their constructor are problematic, but structs with exposed fields--unlike those with exposed read-write properties--never modify `this`. The semantics of such structs are different from those of classes, but in many cases they are vastly cleaner and clearer than those of mutable classes, while being more convenient and clearer than those of immutable classes or so-called "immutable" structs. – supercat Sep 11 '12 at 21:07
0

If your intent is prohibit assignments during compilation time, than you have to stick to constructor assignments and private setters. However it has numerous disadvantages - you are not able to use new member initialization, nor xml deseralization and etc.

I would suggest something like this:

    public class IssuerRecord
    {
        public string PropA { get; set; }
        public IList<IssuerRecord> Subrecords { get; set; }
    }

    public class ImmutableIssuerRecord
    {
        public ImmutableIssuerRecord(IssuerRecord record)
        {
            PropA = record.PropA;
            Subrecords = record.Subrecords.Select(r => new ImmutableIssuerRecord(r));
        }

        public string PropA { get; private set; }
        // lacks Count and this[int] but it's IReadOnlyList<T> is coming in 4.5.
        public IEnumerable<ImmutableIssuerRecord> Subrecords { get; private set; }

        // you may want to get a mutable copy again at some point.
        public IssuerRecord GetMutableCopy()
        {
            var copy = new IssuerRecord
                           {
                               PropA = PropA,
                               Subrecords = new List<IssuerRecord>(Subrecords.Select(r => r.GetMutableCopy()))
                           };
            return copy;
        }
    }

IssuerRecord here is much more descriptive and useful. When you pass it somewhere else you can easily create immutable version. Code that works on immutable should have read-only logic, so it should not really care if it is the same type as IssuerRecord. I create a copy of each field instead of just wrapping the object because it may still be changed somewhere else, but it may not be necessary especially for sequential sync calls. However it is safer to store full immutable copy to some collection "for later". It may be a wrapper though for applications when you want some code to prohibit modifications but still have ability to receive updates to the object state.

var record = new IssuerRecord { PropA = "aa" };
if(!Verify(new ImmutableIssuerRecord(record))) return false;

if you think in C++ terms, you can see ImmutableIssuerRecords as "IssuerRecord const". You have to take extracare though to protect objects that are owned by your immutable object that's why I suggest to create a copy for all children (Subrecords example).

ImmutableIssuerRecord.Subrecors is IEnumerable here and lacks Count and this[], but IReadOnlyList is coming in 4.5 and you can copy it from docs if wanted (and make it easy to migrate later).

there are other approaches as well, such as Freezable:

public class IssuerRecord
{
    private bool isFrozen = false;

    private string propA;
    public string PropA
    { 
        get { return propA; }
        set
        {
            if( isFrozen ) throw new NotSupportedOperationException();
            propA = value;
        }
    }

    public void Freeze() { isFrozen = true; }
}

which makes code less readable again, and does not provide compile-time protection. but you can create objects as normal and then freeze them after they are ready.

Builder pattern is also something to consider but it adds too much of "service" code from my point of view.

aiodintsov
  • 2,545
  • 15
  • 17