C# protected property or field

Do you think it's better to always make protected class members an auto-imple开发者_运维百科mented protected property to keep isolation or make it protected field is enough?

protected bool test { get; set; }

or

protected bool test;

Generally, you should use autoproperties - this allow you to easily add verification, or anything else you need later on. This is especially important if the protected member will be used by classes outside your assembly, as adding such code won't break your contract with them, whereas changing a field to a method or property will.

The suggested practice is to make it a property. The signature changes depending on whether it's a field or a property, which can cause problems if you're crossing assemblies. If you make it a property to begin with, you'll never have this problem. (often later you want to add logic when the property is read or written.)

In C#, auto-implementing the property is so easy, there's no reason not to do it.

Also, it makes things more clear. If it is really meant to be used by the outside world as part of the functioning of the object, make it a property. Otherwise, a future programmer might wonder if you made a field protected instead of private by accident.

I know this question is old, but I would answer it based on the scope of the value as well as where it needs to be initialized or written to. I try to use the tightest scope possible. Hopefully the following will make it more clear on how to decide:

Protected values: This assumes the value only needs to be accessed by the base class and/or the inheriting class, and not by any outside code...

1. When the inheriting class has to read, but never has to modify the value:

   • If the value can be written once in the constructor of the base class, use the following, which prevents the inheriting class from writing to it, and goes a step further and only allows it to be set in the constructor:

     protected readonly bool test;

   • If the value can be written to in a different method other than the constructor, but still only in the base class, use the following, which prevents the inheriting class from writing to it, but allows it to read:

     protected bool Test { get; private set; }

2. When the inheriting class can modify the value, use the following, which allows both the inheriting class and the base class to write to it at any point:

   protected bool test;

Private values: This assumes the value only needs to be accessed from within the class it is declared in.

1. If it can only be set once in the constructor, use:

   readonly bool test;

2. If it can be set anywhere in the class, use:

   bool test;

Also, don't forget that if you declare it as a property, it should use PascalCase. If you declare it as a member variable, it should use camelCase. This will make it easier for other developers to understand the scope.

property, backed by a private field.

This question might be useful

You should never allow direct access to a member variable from outside your class. Either use an auto-generated property or a property with a backing field. If you allow direct access, it can lead to some really bad debugging headaches when multiple methods change that value in a derivation chain and you don't know which one is causing the bug.