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.

Martin Harris · Accepted Answer · 2009-12-09T21:55:05.523

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.

Thanks, the decompiled code makes it very clear. How do you do that with Resharper? — Daniel T., Dec 09 '09 at 21:53
Just to avoid confusion - that's the code *resharper* reconstructed from the IL. It is **not** the code the compiler generated. The compiler generates IL, not C#. — Winston Smith, Dec 09 '09 at 21:55
Sorry I didn't mean Resharper - I meant *Reflector* from here (http://www.red-gate.com/products/reflector/). I've edited to clarify — Martin Harris, Dec 09 '09 at 21:56
Oops, I meant reflector too! I knew what you meant and didn't even notice the mistake. My point still stands - it's the code *reflector* reconstructed from the **IL** generated by the *compiler*. — Winston Smith, Dec 10 '09 at 10:50

score 5 · Answer 2 · answered Dec 09 '09 at 21:45

5

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.

answered Dec 09 '09 at 21:45

No Refunds No Returns

8,092
4
32
43

score 3 · Answer 3 · answered Dec 09 '09 at 21:49

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; } }

Does an abstract property create a private backing field?

3 Answers3

Linked