When to use Constructor and when to use Collection Initializer?

Question

I am having a .Net class which has 10 properties like given below: [the datatypes of individual property is just a placeholder here and it can be anything from a primitive type to an object to a list of objects]

class MyClass
{
   internal int Property1{Get;Set;}
   internal string Property2{Get;Set;}
   internal Myclass2 Property3{Get;Set;}
   internal MyAnotherClass Property4{Get;Set;}   
   internal int Property5{Get;Set;}
   internal int Property6{Get;Set;}
   internal List<string> Property7{Get;Set;}
   internal int Property8{Get;Set;}
   internal MyThirdClass Property9{Get;Set;}
   internal int Property10{Get;Set;}
}  

The purpose of this class is to just hold data and this class will not have any function behavior [similar to POCO classes]. Now I am trying to understand here, as should I create a parameterized constructor in the class and pass it all the values to set these properties or should I use the Collection Initializer to set these properties.

In all cases, all the properties would be set so there is no question of setting selective properties.

If I go ahead with the approach of using constructor then I would create the private members for each of these properties and use them inside the constructor to assign it the respective values. This will avoid calling 10 Setter methods just to create one object of MyClass, but will result in creating a constructor which takes 10 parameters.

Is there a documentation which explains in which case one is advised to use constructor instead of Collection Initializer and Vise a versa? I personally prefer creation of Constructor.

Answer 1

Since it is an internal class, there is no benefit to using read/write automatic properties; you are creating lots of get/set methods in your resultant IL.

Assuming you are using C# 6, you have two options:

1 Make the class invariant:

internal class MyClass
{
    internal MyClass(int property1, int property2, int property3, int property4, int property5, 
                     int property6, int property7, int property8, int property9, int property10)
    {
        Property1 = property1;
        Property2 = property2;
        Property3 = property3;
        Property4 = property4;
        Property5 = property5;
        Property6 = property6;
        Property7 = property7;
        Property8 = property8;
        Property9 = property9;
        Property10 = property10;
    }

    internal int Property1 { get; }
    internal int Property2 { get; }
    internal int Property3 { get; }
    internal int Property4 { get; }
    internal int Property5 { get; }
    internal int Property6 { get; }
    internal int Property7 { get; }
    internal int Property8 { get; }
    internal int Property9 { get; }
    internal int Property10 { get; }
}

The disadvantage to this approach is that you now have a constructor with ten parameters, which is a definite code smell and cumbersome to use.

2 Use fields and initialise the class via an object initializer:

internal class MyClass
{
    internal int Property1;
    internal int Property2;
    internal int Property3;
    internal int Property4;
    internal int Property5;
    internal int Property6;
    internal int Property7;
    internal int Property8;
    internal int Property9;
    internal int Property10;
}

...

var x = new MyClass
{
    Property1 = 1,
    Property2 = 1,
    Property3 = 1,
    Property4 = 1,
    Property5 = 1,
    Property6 = 1,
    Property7 = 1,
    Property8 = 1,
    Property9 = 1,
    Property10 = 1,
};

The disadvantage to this approach is that you now have a mutable data object, which is unlikely to be what you want.

One way to get around this is to refactor the class into a number of separate classes, each with 3-4 values. Whether this is practical or desirable in your case is difficult to tell as your example lacks any information on what the real values are.

Answer 2

From what you've described, it sounds like it would make more sense to have a constructor with 10 parameters and make the property setters private.

Within the constructor, you would then assign the properties from the parameters.

A discussion which runs and runs is whether you should set the member variable directly in the setter rather than use a property. Yes, there is a minimal performance hit but IMHO that is syntactically preferable to referring to the property storage directly in the constructor and the property elsewhere.

As for when you'd use constructors or properties, that depends on the design. If there are known collections of properties you'd wish to set up, then you may wish to create a number of constructors. Alternatively, you may just wish to allow an empty constructor and have the user set any properties they wish. Clearly the constructor gives more control as some properties may have certain business rules. Ultimately, it is a design decision - there are no real rules of thumb to apply here.