Using backing fields inside a class

Question

In cases where we are using properties with backing fields, is it good practice - in terms of OOP and encapsulation - to access these backing fields directly or should we always go through the class property?

public class SomeClass
{
   private string _name;

   public string Name
   {
      get { return _name; }
      set { _name = value == null ? "" : value; }
   }

   public void SetField()
   {
      ...
        _name = "alice";
      ...
    }

   public void SetProperty()
   {
      ...
      Name = "bob";
      ...
   }
}

My instinct is to always use the property and never use the field except in the getter/setter but I don't know if this is an personal preference or there is a preferred standard or rule.

Just to clarify because I don't want to be misunderstood, I know that setting _name and Name are different things and I'm not asking if a setter like the one in my example is a good idea.

EDIT: Im not asking if and when I should use auto properties like the duplicated question/answer mentions.

@DanielMann Because you can´t create any body in their getter/setter in order to implement some business-logic there? E.g. some validation before setting the actual value? — MakePeaceGreatAgain, Jun 11 '19 at 21:00
@DanielMann lets say you have some extra logic in the getter/setter — Slack Groverglow, Jun 11 '19 at 21:02
@HimBromBeere You didnt even read my question and you marked it duplicate, nowhere am I asking if I should use auto-implements or not — Slack Groverglow, Jun 11 '19 at 21:04
Why would you ever 'need' a public method to set a public property? Needing additional logic in a getter/setter just means an auto implemented prop is the wrong choice in that case. It doesnt mean they cant be relied upon — Ňɏssa Pøngjǣrdenlarp, Jun 11 '19 at 21:17
If you think about it, it makes sense to call the Property since you can have additional logic for the setter / getter. Performance wise it's not an issue since properties are inlined at compile time. — Cosmin Sontu, Jun 11 '19 at 22:52
Not a duplicate but highly related: [Fields vs Properties for private class variables](https://stackoverflow.com/questions/1545297/fields-vs-properties-for-private-class-variables). The dupe for that post is also worth reading. — Zohar Peled, Jun 12 '19 at 09:42

score 2 · Accepted Answer · answered Jun 12 '19 at 07:23

As properties are nothing but a get- and set-method around a backing-field, they often implement some logic that should run when you access that property - most commonly some validations.

Imagine e.g the following property representing a persons age:

int Age { get; set; }

Without any logic you can assign any int to that property, e.g. a negative value. Therefor you introduce some validation in the setter:

int Age {
    { get => return _age; }
    { set => _age = value > 0 ? value : 0 }
}

In your class you usually have control about the values being set. Having said this there´s no real need to validate the input. However I feel it´s better to do so anyway in order to have a single point of member-access. Furthermore it´s simple to fortget what valid actually means when your class becomes bigger. Thus you may quite easy write the following which will cause you headaches when executing your code, as it bypasses your validation:

_age = -10;

In fact it´s rarely that simple. You´d have to scan all possible places where your backing-field is touched in order to determine where that invalid value came from.

So I prefer using the properties in the declaring class also.

Using backing fields inside a class

1 Answers1