views:

56

answers:

4

Sorry if this is a bit random, but is it good practice to give all fields of a class a value when the class is instanciated? I'm just wondering if its better practice to have a constuctor that takes no parameters and gives all the fields default values, or whether fields that have values should be assigned and others left alone until required?

I hope that makes sense, Becky

A: 

Ideal practice is to have an object in a usable state as soon as the constructor returns. This reduces errors whereby a partially 'ready' object is inadvertently used.

Mitch Wheat
+1  A: 

Your class' constructor should accept enough parameters to be in an usable state.

You can get the same functionality you seem to be looking for by using Optional Parameters in your constructor.

That way you can set by name just the properties that you have to, and leave the rest with default values until you need to change them.

Sub Notify(ByVal Company As String, Optional ByVal Office As String = "QJZ")
   If Office = "QJZ" Then
      Debug.WriteLine("Office not supplied -- notifying Headquarters")
      Office = "Headquarters"
   End If
   ' Code to notify headquarters or specified office.
End Sub

Remember that optional parameters must be after all non optional parameters.

voyager
A: 

I don't know if it makes a performance difference or not, but any fields for which you have explicit default values I personally prefer to assign them in the declarations, as so:

Public Class MyClass
    Private pIsDirty As Boolean = False
    Private pDated as Date = Now()
End Class

Keep in mind most "simple" types like boolean, integer, etc. auto-default and don't NEED to be initialized, but I show that here as example and sometimes for clarity you want it anyway. Additionally since any classes I write are all for internal use (we don't sell any code objects for public use) I can be assured to the consumer of my classes. So I generally just write a minimal constructor (if a non-default one is needed) that only takes the primary fields, and spin up any additional values with the new With syntax in VB as so:

Dim myObj = New SomeClass() With { .Prop1 = "value", .Prop2 = Now() }
eidylon
That With syntax looks brilliant, I think I'll go with that as it'll cut out all my parameter-laden constructors :o)
Becky Franklin
There is no need to initialize a variable to its default value. http://msdn.microsoft.com/library/ms182274(VS.90).aspx
Tim
Correct Tim, as I said some datatypes default already, and don't really NEED to be initialized. Some people may prefer to for clarity, or organizational standards, or who knows. I simply used those variables as quick examples. The code given was just a [very] quick and dirty example.
eidylon
Sorry, this is a bad answer. This strategy is good *only* for behaviour-less data holder classes (*if* even there!) and for nothing else. I would even say that this is code smell since it makes the class’ API harder to use, allows for instances to be in an uninitialized state and is basically just lazy. eidylon even stated as much, saying “since any classes I write are all for internal use I can be assured to the consumer” – even if true, this is basically the antithesis to good class design. To paraphrase Josh Bloch: write every class as if it were a public API, there are only benefits.
Konrad Rudolph
Other arguments aside, it actually does not leave the class in an inconsistent state. Any fields which need to be initialized and have default values are being explicitly initialized (or left implicit for intrinsic types, as per Tim's comment). And if there are certain fields which must be set to something, and which do not have a usable and acceptable default, then in that case i would write a constructor which exposes specifically those fields which are required to be set by the end user... thereby enforcing the class is always in a usable state, and remove the default constructor.
eidylon
A: 

It depends. How do you intend to use the class? What is the purpose of the class? (i.e. is it an entity class for database modeling or some other class)

I always make my entity classes with nullable properties that are all null when the class is instanced with a constructor that takes no parameter. Then when I call .Load I know all properties reflect the database.

Adding a constructor that calls .Load and assigns all of the properties known values from the database would be a feasible route also.

If you are not referring to an entity modeling class then it really depends on your usage of the class.

My personal preference is to assign all properties a known value (from constructor parameters) and therefore the class is in a known - neutral state.