Question about constructor overloading

  • Thread starter Thread starter Sam Sungshik Kong
  • Start date Start date
S

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
 
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!)
 
James Curran said:
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.
Click to expand...

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
 
Thanks for the answer.
I have an additional question in-line.

James Curran said:
Option 1 is better for the simple reason:

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

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
 
Sam Sungshik Kong said:
If this is BOOM, then is a constructor Person(string name) a must, not an
option?
Click to expand...

I would say so.
Date dateOfBirth is a value type and will be automatically initialize,
right?
Click to expand...

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!)
 
Sam Sungshik Kong said:
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?
Click to expand...

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
 
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
*************
 
Alan Pretre said:
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.
Click to expand...

No need for that unless you've got no other constructors. The default
constructor is only provided automatically if there are no other
constructors.
 
Jon Skeet said:
No need for that unless you've got no other constructors. The default
constructor is only provided automatically if there are no other
constructors.
Click to expand...

Thanks.

-- Alan
 
Back
Top