3

I'm new to C# and was reading the article about the virtual keyword at the MSDN. In their example code, they create the following class:

public class Dimensions
{
    protected double x, y;

    public Dimensions()
    {
    }

    public Dimensions(double x, double y)
    {
        this.x = x;
        this.y = y;
    }

    public virtual double Area()
    {
        return x * y;
    }
}

Why did they add the first constructor (the one that does not require any parameters)? I get that the two double values x and y default to 0 so adding this constructor does not hurt. But I've seen this now numerous times and am therefore wondering if there is any special reason behind always adding such a constructor? Should I always do this?

Niko
  • 26,516
  • 9
  • 93
  • 110
  • possible duplicate of [Should we always include a default constructor in the class?](http://stackoverflow.com/questions/3692042/should-we-always-include-a-default-constructor-in-the-class) – Niko Mar 03 '13 at 11:29

4 Answers4

10

A class by default contains a default constructor. When you add a parametrized constructor the default provided constructor is no longer present.

thus, if you need a parameter-less constructor you need to add it manually, once you added parametrized constructor.

So, to answer your question completely. No you don't have to add the default constructor. But in this case the author of the class allows to create a new Dimensions object, where the values are defaulted to 0.


As a side note to Vlad's answer regarding serialization:

If you have the need for a parameter-less constructor for serialization purposes only, it is good to know that you can mark the constructor as private (or protected) constructor. Serialization (or, de-serialization in that case) can access the private constructor, while business logic couldn't. That way you don't have to 'pollute' the interface towards your business logic.

bas
  • 13,550
  • 20
  • 69
  • 146
2

Should you always do it? Definitely not. You should not include a parameterless constructor when there is no situation in which such a constructor would be valid.

So, if there are sane defaults you can set, and that seems useful, then go ahead and create it. If not, though, leave it out, to force clients to provide the appropriate parameters.

Note that there are some external factors which may require a parameterless constructor. Many types of serialization, for instance.

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
2

The constructor without parameters (Default constructor) is still needed in some cases. One of these cases is serialization.

Read the explanation here

During an object's de-serialization, the class responsible for de-serializing an object creates an instance of the serialized class and then proceeds to populate the serialized fields and properties only after acquiring an instance to populate.

You can make your constructor private or internal if you want, just so long as its parameterless.

Community
  • 1
  • 1
VladL
  • 12,769
  • 10
  • 63
  • 83
1

You might not know what the values are or not be able to set them when you first create the object (e.g. - serialization). If you create an overloaded constructor, then the default construcotr is not created for you implicitly - so you need to create it yourself. see: Should we always include a default constructor in the class?

Community
  • 1
  • 1
omer schleifer
  • 3,897
  • 5
  • 31
  • 42
  • Thanks for the link, this is basically the same question (didn't know that it's called a "default constructor"). – Niko Mar 03 '13 at 11:30