5

According to MSDN's design guide for constructors,

"If you don’t explicitly declare any constructors on a type, many languages (such as C#) will automatically add a public default constructor. (Abstract classes get a protected constructor.) Adding a parameterized constructor to a class prevents the compiler from adding the default constructor. This often causes accidental breaking changes."

Why not:

"If you don’t explicitly declare any default constructors on a type, many languages (such as C#) will automatically add a public default constructor. (Abstract classes get a protected constructor.)"

What is the reason behind this?

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Rajes
  • 1,036
  • 10
  • 15
  • Please note that the term "default constructor" only applies to the one that the C# compiler adds. If you add a parameterless constructor yourself, this is *not* the default constructor. – Lasse V. Karlsen Jun 15 '16 at 11:10
  • It's the same reason `private` exists: It takes away dangerous and undesirable options from API users. `private` is strictly unnecessary for the language to function. It only takes options away. – usr Jun 15 '16 at 11:12
  • 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) – Igoranze Jun 15 '16 at 11:42

3 Answers3

14

Because not all classes should be constructed parameterless.

Consider a class that is designed to implement the interface between your application and a file on disk. It would be very inconvenient having to handle the case where the object is constructed without specifying which file to manage.

As such, since the main point of creating a non-static class is that you want to create objects of it, you're spared having to add an empty parameterless constructor if that is all you want to have.

Once you start adding constructors at all, then the automagic is disabled and no default constructor will be provided.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
6

If I define a custom constructor which means my object need initialising in a specific way e.g.:

class Customer
{
    public Customer(string name) { this.Name = name; }
    public string Name { get; }
}

If the compiler also added public Customer() then you could bypass the requirement to initialise a customer with a name.

Trevor Pilley
  • 16,156
  • 5
  • 44
  • 60
2

If no constructor is present, there is no way to new up an instance of the class.

So, when you provide a constructor, there is at least one way to construct the class. If no constructor at all is provided, one is provided by default, so that you can actually build the class.

This answer's the question of why the default constructor exists, but not why it doesn't exist when you don't create your own parameterless constructor.

If a default constructor were to be provided when you've already provided one, this could lead to unintended consuming of the class. An example of this has been pointed out in another answer, but just as another:

public class Foo
{

    private readonly IDbConnection _dbConnection;

    public Foo(IDbConnection dbConnection)
    {
        if (dbConnection == null)
            throw new ArgumentNullException(nameof(dbConnection));

        _dbConnection = dbConnection;
    }

    public Whatever Get()
    {
        var thingyRaw = _dbConnection.GetStuff();
        var thingy = null; // pretend some transformation occurred on thingyRaw to get thingy
        return thingy;
    }

}

If a default constructor were to be automatically created in the above class, it would be possible to construct the class without its dependency IDbConnection, this is not intended behavior and as such, no default constructor is applied.

Kritner
  • 13,557
  • 10
  • 46
  • 72