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?
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.”
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.