5

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.

  • The question you should ask yourself is, if all you need is the data and there are absolutely no rules for it, why would you need an object in the first place? Why wouldn't you simply go with List<int> instead? – Andy Oct 9 '15 at 11:21
  • I am sorry I put the int, just as a placeholder and it can be any datatype/object. Let me edit the question again to make it more explicit. – GawdePrasad Oct 9 '15 at 11:24
  • You are most likely going to use this model to transfer data... You are going to extract data from this model and do operations on it. That is against OOP. If you need to rip some data and perform operation on it, why couldn't the object do it instead and return you the data with the operation already done? Wouldn't it be better? Non-functional object are pretty useless, provide no benefit and mimic procedural programming techniques. – Andy Oct 9 '15 at 11:29
  • @DavidPacker The object of this class will be used like a POCO entity and will be used as link. Hence I am encpasulating just the data in this class which will be read from different tables on Data store – GawdePrasad Oct 9 '15 at 11:33
  • I am probably so used to DDD that I can't see any other way anymore. And that is my problem. Your application design is mostly likely completely different than mine. In DDD, having a model like yours is a huge red flag, that's why I expressed my concerns. – Andy Oct 9 '15 at 11:44
6

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.