C# protected readonly autoproperty with only a get accessor vs protected readonly field

Question

Some of my classes use a protected readonly field that represents a logger. Below is some sample code -

public class RunJob {
    protected readonly ILogger logger;
    public RunJob(ILogger logger) { this.logger = logger;}
    public virtual void ProcessFiles() { 
        logger.Log("Start");
         ... 
        logger.Log("End"); 
    }
}

Having gone through many articles/threads on properties vs fields, I realize that protected fields are considered bad but I'm wondering if I will gain any real practical benefits by making logger a property. Considering my use case above, is there any real difference between the below 3 -

1. protected readonly ILogger logger;
2. protected ILogger Logger { get; } or perhaps (protected ILogger Logger {get; private set;} - which is readonly only for subclasses)
3. #2 backed by a private _logger object

In my application, #1 works well enough - The logger object is initialized once in the constructor and is then used throughout the class (and its subclasses), this class and its subclasses do nothing other than calling logger.Log(...) and no one except for this class and its subclasses cares whether it's a field or property.

I have gone through this thread but many questions remain unanswered -

1. One benefit that could've been applicable here is that the properties can be overriden, but in C# they're sealed by default (unless properties work different than methods). So, unless the developer intentionally makes a property virtual, this benefit is not applicable.

2. Are there any performance benefits to be gained by using a readonly field? Surely, the compiler etc would have to work a little extra to make readonly properties work?

I do see the overall benefits of properties over fields in principle and even though it's just one line of change in my case, I wonder if I'm doing it just because it's a new cool fad or whether it really truly applies in this case?

Answer 1

I'd probably not overthink the issue - it is not that important in the greater scheme of things.

Yes, properties are much more future-proof and flexible:

1. You can set its value internally if it needs to be changed during instance's lifecycle protected ILogger Logger {get; private set;}.
2. You can make it Lazy : private readonly Lazy<ILogger> _logger; protected ILogger Logger {get {return _logger.Value; }}.
3. You can proxy it to some other object protected ILogger Logger {get {return _someParentObject.Logger; }}.
4. You can even make it dependent on some other piece of state protected ILogger Logger {get {return IsA ? _a : _b; }}.
5. etc.

, but readonly protected fields aren't actually that bad:

1. because they are readonly, unlike mutable fields that are much much worse. Obviously, it is even better if they are also immutable or stateless(like it is probably in your case).

So: either make it a property so you don't have to worry about any future changes, or just leave it as it is - KISS and YAGNI. Again - it is not so important to dwell on it too much.

Answer 2

I would not care about performance difference in this case at all because it's so minor unless you have a really really good reason for it. You can read about premature optimizations here e.g. Otherwise I don't personally see a point of creating protected properties in this case. The reason for a property rather than a field is that you can control the assignment, which in this case you don't really need, since planned use is to just read it anyway. Though in theory children could override logger and it's not good probably. But in practice I doubt this could happen.

Regarding 2 vs 3, 2 is just a syntactic sugar over 3 as far as I know. I guess it will even be compiled the same, you can check that.

Answer 3

protected readonly _logger;

and

protected ILogger Logger { get; } 

can be assigned in constructor only.

But

protected ILogger Logger {get; private set;}

is readonly only for subclasses, but can be assigned from any method in the same class;

when you do have backing field, it is more lines of code; I personally would prefer using

protected ILogger Logger { get; }

to avoid exposing field to subclasses, which is considered as a bad practice