58

In C#, the following code is valid 

interface I{
    int property{get;set;}
}

Which doesn't make any sense to me. This seems to break one of the most important principles of interfaces: lack of state (in other words, no fields). Doesn't the property create an implicit private field? Wouldn't that be really bad for interfaces?

Improve this question
7
  • 18
    Is lack of state one of the principles of an interface implementation? To me, an interface is a way to define a contract, i.e. if a class implements such interface, then it has all the methods and properties defined in the contract.
    – Florian Margaine
    Commented Jul 23, 2014 at 21:05
  • 6
    A property is just a get method and a set method. Since interfaces are just a list of methods you have to implement, it's natural that interfaces can have them.
    – Doval
    Commented Jul 23, 2014 at 21:06
  • 1
    @FlorianMargaine Certainly the concept of a contract is the most important principle of interfaces, but lack of state is also important. This helps keep it separate from an abstract class. IE in Java 8 this ends up being the only major difference between interfaces and abstract classes.
    – David says Reinstate Monica
    Commented Jul 23, 2014 at 21:11
  • 3
    Because its not a field. See Why can't C# interfaces contain fields?
    – user40980
    Commented Jul 23, 2014 at 21:14
  • 3
    @Doval: It is natural that an interface declares such methods, but not that it implements them.
    – Giorgio
    Commented Jul 23, 2014 at 22:07

3 Answers 3

Reset to default
79

I think the confusing part is that if you write int Property { get; set; } inside a class, then it's an auto-property with implicit backing field.

But if you write exactly the same thing in an interface, then it's not auto-property, it just declares that the property is part of the interface and that any type that implements the interface has to contain that property (as auto-property or not), but it doesn't create the backing field.

One way to see the difference is to write int Property { get; }: this is valid in an interface and declares a property that has only a getter, but no setter. But it won't compile in a class (unless you're using C# 6.0), because auto-property has to have a setter.

Improve this answer
22

Defining the property as you've shown is the same as defining methods int GetProperty() and void SetProperty(int i). Properties are powerful short-hand in C#.

A property does not implicitly create a private field in C#. That is the default implementation of an auto-property, for example public string MyString { get; set;} - however, a property which defines custom logic in the get method does not generate an implicit private field.

Lastly, as interfaces are concerned with public API, what would it matter if the implementation of an interface property relied on a private field - implicit or otherwise? That is hidden from consumers of the interface regardless.

Improve this answer
2
  • Ahh... I didnt realize it only happens for auto-properties, and since you have to override it, that makes sense. But if the interface was to create an internal private variable, implementers would not have access to it - an obvious problem.
    – David says Reinstate Monica
    Commented Jul 23, 2014 at 21:23
  • 10
    If you define a property in a C# interface, the implementation of that property is left to the implementing class - they can make it an auto-property, or define custom logic as they see fit. No field is added to the interface.
    – NWard
    Commented Jul 23, 2014 at 21:28
16

Properties are methods! A backing field will be added to the class which implements the interface (either manually or through an auto-property).

Improve this answer
3
  • Sometimes there will be no backing field. Though it would be rare to define both a get and a set and not have a backing field for it.
    – Stephen
    Commented Jul 24, 2014 at 9:01
  • 1
    +1 Properties are methods! yes! I like writing Propertymethods but code-reviewing co-workers don't see it that way and we really miss opportunities for some nice expressive encapsulations in our programs.
    – radarbob
    Commented Aug 2, 2014 at 20:52
  • 1
    Those "property methods" should be quick though, like no DB lookups or anything. There's an implied contract that property access is fast, Get* methods can be slow.
    – Trey Mack
    Commented Aug 19, 2016 at 6:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.