When should we use private variables and when should we use properties. Do Backing Fields should be used in same class ?

Question

In most of the cases we usually creates a private variable and its corresponding public properties and uses them for performing our functionalities.

Everyone has different approach like some people uses properties every where and some uses private variables within a same class as they are private and opens it to be used by external environment by using properties.

Suppose I takes a scenario say insertion in a database. I creates some parameters that need to be initialized.

I creates 10 private variables and their corresp public properties which are given as

private string name;
public string Name
   {
     get{return name;}
      set{name=value;}
   }

and so on. In these cases mentioned above, what should be used internal variables or properties.

And in those cases like

public string Name
   {
     get{return name;}
     set{name=value>5?5:0;} //or any action can be done. this is just an eg.
   }

In such cases what should be done.

What is the conclusion

I actually meant to ask this. Should we use variables within that class or not or should we use properties everywhere within same class as well.

Answer 1

I never expose public variables. Why? Because I can't lay constraints on them, whereas I can when I'm using properties. I can first check the value if it meets my constraints (e.g. an email address) and then I save it. Otherwise I throw an Exception.

Answer 2

If the only use for the private variable is as a storage container, you might use:

public string Name {get; set;}

IMHO one should never make variables public - always use properties so you can add constraints or change behaviours later on whitout changing the interface.

Answer 3

Made things more readable:

• I expose my data always through properties.
• If I do not need additional logic (e.g. validation) I use implicit properties. This way there is no backing field and I cannot access it by accident. If I need to add some additional logic I can easily change the implicit property to a "traditional" one. As I use the property everywhere I do not have to worry that my extra logic is not called.
• If I need something extra (like validation) then I have a private backing field, but I access this field only in the property body (get/set accessors). Again I do not need to worry if I change something in the property: My code will always use the same logic.
• The only reason for not calling the property in my opinion would be if for some reason I really do not want any additional logic to be called, but this seems a dangerous thing so I rather avoid it...

Answer 4

If you use auto-implemented properties, then the field will be hidden, so you are forced to use the property, even in the class where the property is defined. Auto-implemented properties are a good idea, unless you need to add some logic to the getter/setter.

Answer 5

You should never expose public variables without a very good reason. It is tough to say never, because if you trying to interop with comm type components you might be required too.

Anything publicly exposed should be a property. Why is that?

The reason is if you need to change the source of the value, or add some business logic checking if it is a public member you are going to require anything using the code to change. If it is a property you can change the internal logic and not require anybody using it to change the code.

I personally use properties and only create members variables when I want a property to do more than getting or setting (since this is easy with C# 3.0 with shortcut properties).

If I want to keep a property from being publicly exposed I make it as private, and only expose it when I have too.