Constructor or properties: which one is the better choice while assigning values

Question

When we should use constructor over properties or vice versa while assigning values.

Answer 1

A constructor is a very convenient and powerful type of contract - a way to require consumers to provide certain information before they can even use your object. So for information that is necessary for the instance to function properly, use constructor parameters. This is the underlying concept of dependency injection - anything you depend on to do your job, must be injected (provided) to you before you begin.

Properties can represent an interesting problem. In general, experience has taught me that wherever possible, properties should be read-only and objects should generally be as externally immutable as possible. Adding a public setter to a property is a multiplier of complexity for your class. There are of course always types of objects - entities are a good example - where setters make sense. But for most objects, the pattern of "write-to via constructor" / "read-from via properties" for state has vastly reduced complexity and bug risks in the applications I've been responsible for.

Answer 2

Use constructor if the parameter values are really required for your object to be constructed (without them the object cannot start to live). Use properties for the parameters which have an acceptable default value, so it's OK not to assign them at all. You can provide some extra constructors which will assign some properties as a shorthand, courtesy to your users.

Answer 3

You use a constructor when you need arbitrary sane initial values, and properties when you want the values to be changeable later.

Answer 4

There are a few cases where mutable properties may be preferable:

1. For 'pure' mutable Data objects where merely setting the properties can have no side effects. For instance, you might have an object that represents some Entity in the database, but modifying its properties will not have any effect until you explicitly perform a Commit operation. The object is a package for containing data, but nothing directly reacts to changes in the data.

2. If you have a large amount of configurable state that will affect some operation and many of the configurable properties have meaningful default values. If these are properties of the class that performs the operation, it's typical to have some notion of 'freezing' the state so that the mutable properties throw exceptions while the operation is running.

3. If you're developing a class that will be consumed by a visual designer or other system that relies on Reflection over properties. For instance, the data binding system in WPF makes extensive use of mutable properties as a way to communicate UI interactions. With a proper design to manage these mutations, you can create some very powerful and responsive interfaces.