Parameterless Constructors - Best Practices?

[Robert Zurer]

Hello All,

Is it considered a best practice to always write a parameterless constructor
for any object - just in case?

I'm not sure. I want my object to have all it absolutely requires to function
in the world at birth. Defining a parameterless constructor allows it to be
created in an unstable state.

On the other hand

1. XmlSerializer doesn't like objects without one. Web Services have a problem
with this

2. The generic new() constraint takes no parameters

3. It's kind of handy to be able to just call Activator.CreateInstance with
just a Type. (Dependency Injection is easier simply assigning properties after
the fact.)


Any other pros or cons??


Thanks


Robert Zurer

 

[shiv_koirala]

From previous quote :- Defining a parameterless constructor allows it
to be created in an unstable state.
Reply - Not necessary i am sure there are many buisness objects which
does not have to be at any state after initialization and thats there
stability.

I would say we need parameter constructor if need to do some
initialization. But according to your saying you mean i should and must
have a constructor with parameter is not possible practically.
-------
Regards ,
C#, VB.NET , SQL SERVER , UML , DESIGN Patterns Interview question book
http://www.geocities.com/dotnetinterviews/
My Interview Blog
http://spaces.msn.com/members/dotnetinterviews/

 

[Guest]

Hi Robert,

I think it depends on how "general" you want your class to be. Most classes
in commercial class libraries have a parameterless constructor, and lots of
little methods for customising the object before it is used. However, there
is a lot of work in this, and it is unnecessary if the class just exists
within your own application. In this case, I don't waste too much time
getting the constructor "perfect" - I try to keep it simple, but if I want to
add a parameter to makes the class easier to use, then I add it (however, at
about 3 or 4 parameters, I become concerned)

- Javaman

 

[Jon Skeet [C# MVP]]

Is it considered a best practice to always write a parameterless constructor
for any object - just in case?

No - not where it makes sense.

I'm not sure. I want my object to have all it absolutely requires to function
in the world at birth. Defining a parameterless constructor allows it to be
created in an unstable state.

That's a worthy goal, but...

On the other hand

1. XmlSerializer doesn't like objects without one. Web Services have a problem
with this

2. The generic new() constraint takes no parameters

3. It's kind of handy to be able to just call Activator.CreateInstance with
just a Type. (Dependency Injection is easier simply assigning properties after
the fact.)

Activator.CreateInstance isn't an issue as far as I'm concerned, but
dependency injection certainly is.

I would consider components which need collaborators as somewhat
different from the kind of object which is intimately tied to
configuration, and which it makes no sense to reconfigure.

Consider a FileStream - it doesn't make any sense to have a "File"
property which can changed during the course of the lifetime of the
stream. That suggests not having a parameterless constructor.

On the other hand, consider something with an authentication
collaborator. It may well make sense to change the configuration at
runtime, even if you don't do it in practice - it doesn't fundamentally
screw things up.

I think where I'm going with this is: if it's the kind of object which
would be used in dependency injection, a parameterless constructor
might well be a good idea

 

[Robert Zurer]

Activator.CreateInstance isn't an issue as far as I'm concerned, but
dependency injection certainly is.

<other good stuff>

Thanks Jon. As always, your response was right on the the mark.


Robert Zurer