468,133 Members | 1,368 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,133 developers. It's quick & easy.

Parameterless Constructors - Best Practices?

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
Nov 17 '05 #1
4 6882
>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/

Nov 17 '05 #2
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

"Robert Zurer" wrote:
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

Nov 17 '05 #3
Robert Zurer <ro**********@zurer.com> wrote:
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 :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 17 '05 #4
In article <MP************************@msnews.microsoft.com >, sk***@pobox.com
says...
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
Nov 17 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

136 posts views Thread by Matt Kruse | last post: by
13 posts views Thread by john doe | last post: by
4 posts views Thread by Luis Esteban Valencia | last post: by
10 posts views Thread by jojobar | last post: by
reply views Thread by Louis Aslett | last post: by
1 post views Thread by Pablo | last post: by
27 posts views Thread by didacticone | last post: by
1 post views Thread by gcdp | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.