Question about constructor overloading

[Sam Sungshik Kong]

Hello!

I am wondering what's the best practice about setting object data using
constructor parameters.

Let's say that I am creating a Person class.

class Person
{
private string name;
private Date dateOfBirth;
public Person()
{
}
public string Name
{
get {return name;}
set {name = value;}
}
public Date DateOfBirth
{
get {return dateOfBirth;}
set {dateOfBirth = value;}
}
}

Now I have options regarding how to set name and dateOfBirth.

1)

public Person(string n, Date d): this()
{
name = n;
dateOfBirth = d;
}

When using the class,

Person person = new Person(name, dob);


2)

Person person = new Person();
person.Name = name;
person.DateOfBirth = dob;


OK.
Now I want to know what's the guideline regarding the above case?
Option 1) seems to be better.
However, if there are many parameters, I need to provide all the overloading
constructors for every combination of parameters.
For example,

public Person(string n): this()
{
name = n;
}

public Person(Date d): this()
{
dateOfBirth = d;
}


Option 2) is simple.

I feel that I need some guidelines about what data should be in the
constructor's parameters.


TIA.
Sam

 

[James Curran]

Option 1 is better for the simple reason:

Person p = new Person();
Console.Write(p.Name); // BOOM!

Your worry is a false lead. You don't have to create most of those,
because you *shouldn't* create most of those. You need write just the ones
that will create a valid object. In your example, that's probably just the
one with both parameters. The best way to ensure that you never have an
invalid object, is to make it impossible to create an invalid object.

--
Truth,
James Curran
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
(note new day job!)

 

[Alan Pretre]

You need write just the ones
that will create a valid object. In your example, that's probably just the
one with both parameters. The best way to ensure that you never have an
invalid object, is to make it impossible to create an invalid object.

And also, if the default constructor (no parameters) cannot create a *valid*
object (more info is necessary), then you will want to make that constructor
protected or private so that consumers cannot create an invalid one.

-- Alan

 

[Sam Sungshik Kong]

Thanks for the answer.
I have an additional question in-line.

Option 1 is better for the simple reason:

Person p = new Person();
Console.Write(p.Name); // BOOM!

If this is BOOM, then is a constructor Person(string name) a must, not an
option?
Date dateOfBirth is a value type and will be automatically initialize,
right?

To sum up,

name(reference type) should be in the parameter.
dateOfBirth(value type) is an optional.

Am I right?


Sam

 

[James Curran]

If this is BOOM, then is a constructor Person(string name) a must, not an
option?

I would say so.

Date dateOfBirth is a value type and will be automatically initialize,
right?

Yes... BUT... It will be initialized, but to something that is
definitely wrong. If you let it default initialize, whenever you want to
use dateOfBirth you will have to check to establish is this is a valid
birthday or a bad value. Remember, our goal here is not merely programs
which don't crash but programs that give the correct answers.


--
Truth,
James Curran
Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com
(note new day job!)

 

[Alan Pretre]

If this is BOOM, then is a constructor Person(string name) a must, not an
option?
Date dateOfBirth is a value type and will be automatically initialize,
right?

To sum up,
name(reference type) should be in the parameter.
dateOfBirth(value type) is an optional.

Am I right?

It doesn't matter if you are working with reference or value types.

What matters: If your object is not valid without the name member, then you
want to force the consumer to supply the name. If everything else is
optional, then simply provide the constructor that initializes the name, and
make the default constructor protected or private so that it cannot be
called from the outside. Initialize all of the optional values to
appropriate defaults in your constructor. Then let the consumer override
the default optional values through the properties.

-- Alan

 

[Guest]

hi
i have an opinion
when we create a class we can provide the details which uniquely
identify(primary attribures )in the cunstructor .the secondary details can be
assigned using properties.

eg in an person calss the primary details are persons identity,name ,what
ever..
the secondary details are salary details ,office phone ....

my approach is purely in a business point of view ..

regards
********
ansil
Technopark
Trivandrum
*************

 

[Jon Skeet [C# MVP]]

And also, if the default constructor (no parameters) cannot create a *valid*
object (more info is necessary), then you will want to make that constructor
protected or private so that consumers cannot create an invalid one.

No need for that unless you've got no other constructors. The default
constructor is only provided automatically if there are no other
constructors.

 

[Alan Pretre]

No need for that unless you've got no other constructors. The default
constructor is only provided automatically if there are no other
constructors.

Thanks.

-- Alan