Does an abstract property create a private backing field?

Question

Simple question: does an abstract property create a private backing field? Example:

public abstract Name { get; set; }

Will this create a private backing field? I want to force any class that derives this property to use their own backing field, not one that's created by the compiler.

Answer 1

No. Since it's abstract, the class implementer must implement the property. If the implementer declares it that way, then Yes, it's an automatic property with a hidden member to hold the actual value.

Answer 2

No it doesn't. I just tested with the following class:

public abstract class Class1
{
    public abstract string TestStringAbstract { get; set; }

    public string TestString { get; set; }
}

and decompiled it in Reflector. This was the generated code:

public abstract class Class1
{
    // Fields
    [CompilerGenerated]
    private string <TestString>k__BackingField;

    // Methods
    protected Class1()
    {
    }

    // Properties
    public string TestString
    {
        [CompilerGenerated]
        get
        {
            return this.<TestString>k__BackingField;
        }
        [CompilerGenerated]
        set
        {
            this.<TestString>k__BackingField = value;
        }
    }

    public abstract string TestStringAbstract { get; set; }
}

As you can see only a single backing field was generated for the concrete property. The abstract one was left as a definition.

This makes logical sense since the property must be overridden by any child class there is no point in creating a backing field that there would be no way of ever accessing (since you can't ever access the abstract property).

On the other hand a virtual property will create a backing field and any class that overrides the property with an auto-implemented replacement will create its own backing field at that class's level.

Answer 3

There's a difference between:

public abstract string Name { get; set; }

and

public string Name { get; set; }

The first property declaration doesn't create a backing field. It just creates an abstract property (kind of like an interface method declaration), which has to be implemented by any non-abstract inheriting class.

The second declaration is an auto-property, which DOES create a backing field. It's actually compiler syntactic sugar shorthand for:

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