Why does C# allow properties in interfaces?

Question

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?

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, Jul 23 '14 at 21:05
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, Jul 23 '14 at 21:06
@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, Jul 23 '14 at 21:11
@Doval From what I understand a property implicitly creates a private variable under the hood, so its "more" than just a get/set. — David says Reinstate Monica, Jul 23 '14 at 21:12
Because its not a field. See Why can't C# interfaces contain fields? — , Jul 23 '14 at 21:14
@Doval: It is natural that an interface declares such methods, but not that it implements them. — Giorgio, Jul 23 '14 at 22:07

svick · Accepted Answer · 2014-11-04T22:10:10.323

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.

score 22 · Answer 2 · answered Jul 23 '14 at 21:13

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.

answered Jul 23 '14 at 21:13

NWard

376

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 Jul 23 '14 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 Jul 23 '14 at 21:28

score 16 · Answer 3 · answered Jul 23 '14 at 21:15

16

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

answered Jul 23 '14 at 21:15

Roman Reiner

1,036

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 Jul 24 '14 at 09: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 Aug 02 '14 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 Aug 19 '16 at 06:01

Why does C# allow properties in interfaces?

3 Answers3