Should Constructor initialize its own parameters directly to a private member or through a public field (C #)?

Question

eg. which way is better

class Foo { private string _Bar ; Foo ( string bar) { _Bar = bar ; } public string Bar { get { return _Bar ; //more logic here } set { _Bar = value ; //more logic could be added } } } 

OR

 class Foo { private string _Bar ; Foo ( string bar) { this.Bar = bar ; } public string Bar { get { return _Bar ; //more logic could be added } set { _Bar = value ; //more logic could be added }} } 

Edit: I know that the latter allows some logic to be inserted into it, but it is justifiable to use it because of this ...

Answer 1

Whatever path makes sense for the class; there is no "best practice".

Sometimes you may need to make sure that you perform only the same operations as the property; in this case it makes sense to use a property.

Sometimes you want to do something that can only be done in a constructor that violates what you can do through the post-construction of the property, in which case it makes sense to use this field.

Answer 2

It depends.

I prefer to use properties when there are no side effects. However, there are times when there are other side effects in setting a property, such as an event notification, a potentially unnecessary (at the moment) check, etc. In these cases, setting up a support field directly is the best option.

Answer 3

It depends if you need logic in the public property to be executed, use this method. If you are just doing a direct assignment, then assigning to a private member is fine.

Answer 4

I often use properties, as it only allows me to write my check in one place (property setting tool). This helps to avoid code duplication.

 public class Foo { private string _Bar = String.Empty; public string Bar { get { return _Bar; } set { if (value == null) throw new ArgumentNullException("Bar"); _Bar = value; } } public Foo(string bar) { Bar = bar; } } 

Answer 5

Please read this excellent blog post by Eric Lippert: Automatic vs Explicit Properties :

Here is the question I received from a C # user last year, the question I get fairly often:

User: with "regular" explicit properties, I tend to use a private class directly from within. Of course, with automatic ownership, you cannot do this. my concern is that in the future, if I decide that I need an explicit property for some reason, I am left with the choice of changing the implementation class to use a new private field or continue browsing the property. I am not sure what is the right thing to do in this case.

You say “for some reason” and that key. The answer to your question will completely depend on what is the reason that the change.

If the reason that motivated the automatic property change for the explicit implementation of the property was to change the semantics of the property, then you should evaluate the desired semantics when accessing property from within the class are identical or different from the desired semantics when accessing property from outside the class. [emphasis mine]

Answer 6

Your example is too simple, but your comment "// more logic added" indicates the possibility that the set property may be more complex than simply assigning a private variable.

Do not repeat the same logic in the constructor if you have already encoded the same logic in the property set. This will be unnecessary duplicate code and may be error prone when the logic needs to change, and this is a pain in the neck for the future developer who needs to support your code.

If the set property has some side effect that would be undesirable / unnecessary in the constructor, such as event notification, then you should reorganize the generic code into your own method. The constructor and set property can call this method.

You will get the answer "it depends on me" because, well, it depends. One reason for this is personal preference (often determined by past experience when something was difficult to maintain or distort). Some reason is that each situation is different, and although, of course, there are many common patterns and tasks that we implement with code, there should always be the ability to not follow the norm in order to be creative or innovative in your coding solutions for your problem. Remember that we do not program code, we program solutions using code as a tool.

Answer 7

I will answer the question "depends on me": you are trying to find a balance between ensuring that the internal state remains consistent, duplication of code and performance.

I agree with Adam P, because your current example is very simple, it really doesn't matter.

Consider an example where the readxly Qux variable depends on Bar and another Baz member. Qux is quite expensive to calculate, so you don’t want to do this on the fly - it offers a private field for storing the state and changing its IFF Bar and Baz.

So, in your constructor, you can install Bar and Baz publicly, knowing that Qux will be allowed twice or delay Qux permission until the end of the constructor (and save one call of Qux permission).

In a rather trivial code that is unlikely to change (for example, public properties that support simple private fields), select one style, stick to it and focus on solving real-world program problems.