For example, suppose I want an ICar
interface and that all implementations will contain the field Year
. Does this mean that every implementation has to separately declare Year
? Wouldn't it be nicer to simply define this in the interface?

- 49,224
- 10
- 102
- 153

- 42,611
- 64
- 162
- 244
-
22Interfaces do not have implementation, for this use an abstract class, with the property Year – PostMan Jan 22 '10 at 05:08
-
6To add to what's been said here, interfaces are contracts, and a field is an implementation detail in that it defines a slot in the machine's memory to put a value (either scalar or address pointer) into. – herzmeister Jan 22 '10 at 10:45
-
9But if the field is public, it's part of the contract and not only an implementation detail, right? – Alex Apr 14 '16 at 09:23
12 Answers
Though many of the other answers are correct at the semantic level, I find it interesting to also approach these sorts of questions from the implementation details level.
An interface can be thought of as a collection of slots, which contain methods. When a class implements an interface, the class is required to tell the runtime how to fill in all the required slots. When you say
interface IFoo { void M(); }
class Foo : IFoo { public void M() { ... } }
the class says "when you create an instance of me, stuff a reference to Foo.M in the slot for IFoo.M.
Then when you do a call:
IFoo ifoo = new Foo();
ifoo.M();
the compiler generates code that says "ask the object what method is in the slot for IFoo.M, and call that method.
If an interface is a collection of slots that contain methods, then some of those slots can also contain the get and set methods of a property, the get and set methods of an indexer, and the add and remove methods of an event. But a field is not a method. There's no "slot" associated with a field that you can then "fill in" with a reference to the field location. And therefore, interfaces can define methods, properties, indexers and events, but not fields.

- 647,829
- 179
- 1,238
- 2,067
-
31The one thing I do sometimes miss is a java-like ability to define interface-level constants, which presumably would not require a "slot" to support in the language. – LBushkin Jan 22 '10 at 08:54
-
2I like the explanation in simple words. Thanks. "CLR via C#" and "Essential .net volume 1" provide more details. – Sandeep G B Apr 18 '11 at 05:40
-
8Why doesnt a field have a slot? and same question with operators? I remember hearing about duck typing using reflection to see if an interface is implemented even if the class did not inherit the interface. Why cant reflection (or a slot) be used to pull up a field? i'm still writing my code so i may not need/want fields but i was surprise to find i cannot use operators. operators are exactly like methods from my understanding except not all can be overloaded (`An interface cannot contain constants, fields, operators`. From http://msdn.microsoft.com/en-us/library/ms173156.aspx) – Apr 24 '11 at 07:19
-
@acidzombie: The question of why an interface cannot define operators is different (though maybe related) to why it can't contain fields; I'd suggest posting another question if you're still interested in that. – Adam Robinson Aug 24 '11 at 12:38
-
@LBushkin: I agree, since interfaces should define behaviour and fields is used to implement states, so fields cannot be defined in interfaces, it's clear, but constants aren't states, although they aren't behaviour also. I miss the ability to defines constants in interfaces because constants are suitable to "contracts definitions", so interfaces. – Luciano Aug 30 '12 at 14:19
-
@LBushkin and Luciano -- i disagree. A constant is something ... umm.. well... constant. So if you Foo implements the constant with valuex and Bar implements the constant with valuey, it's not really a constant – danielpops Mar 15 '13 at 02:44
-
@ericlippert, you are missing a valid and important use case where everything would work. Consider an interface for a [mathematical ring](http://en.wikipedia.org/wiki/Ring_(mathematics)). It would be entirely natural for IRing
to have a property public static TRing One {get;}. There is no problem of ambiguity in resolution, because TRing will be known at compile time. Furthermore, the subclassing difficulties you mention elsewhere can be avoided by requiring that any class implementing IRing be sealed. So DoubleRing.One returns the double 1, TwoByTwoMatrix.One the identity matrix, etc. – William Jockusch May 18 '15 at 07:44 -
Worth to add that a field could be declared as a method. I found the workaround when I asked myself, how would that be implemented in Haskell — there, in fact, syntactically no difference between a variable, and a function that always returns the same value. That is it. – Hi-Angel Jul 20 '15 at 09:56
-
@Hi-Angel I don't get how that's a workaround, considering you still have to provide definition to the function outside of the interface (which you'd be doing with the fields anyway.) – arkon Aug 14 '15 at 06:42
-
1@b1nary.atr0phy why with fields? E.g. if I declared a method `int One()`, then the implementation `public int One(){return 1;}` isn't a field. – Hi-Angel Aug 14 '15 at 08:20
-
LBushkin and Luciano. No way to add constants to interface, yes. BTW, as a workaround you can make an extension method returning constant. Extensions in C# can be made not only to classes, but to interfaces too – Deepscorn Jan 18 '21 at 15:19
Interfaces in C# are intended to define the contract that a class will adhere to - not a particular implementation.
In that spirit, C# interfaces do allow properties to be defined - which the caller must supply an implementation for:
interface ICar
{
int Year { get; set; }
}
Implementing classes can use auto-properties to simplify implementation, if there's no special logic associated with the property:
class Automobile : ICar
{
public int Year { get; set; } // automatically implemented
}

- 129,300
- 32
- 216
- 265
-
7Isn't everything that is public a part of the contract. If a class has public int Year, doesn't it say that the class contract has a field of type Year to be present on it, and accessible? – Didier A. Mar 10 '14 at 19:42
-
3Late to the party, but no, in this case it means the contract has a PROPERTY Year which any abiding class is supposed to implement. Properties are actually get/set methods, which have backing field automatically generated if no special logic is needed. Special syntax is just for a clearer notation. – user3613916 Jun 17 '14 at 12:26
-
How can I define a constant default value (like 123) to that automatic implementation of `Year`? – kungfooman Aug 01 '17 at 01:39
-
1@lama12345 I'm also late to the party, but since C# 6 (2015, .NET Framework 4.6 and .NET Core) you can use an auto-property for that purpose. `public int Year => 123;`. However, in this case it makes no sense to have a setter, so the interface would have to be defined with `int Year { get; }` – EriF89 Feb 07 '20 at 11:35
-
Declare it as a property:
interface ICar {
int Year { get; set; }
}

- 5,097
- 23
- 24
-
56The question is "**Why** can't C# interfaces contain fields?". This doesn't address that. – AakashM Jan 22 '10 at 10:37
-
22I agree that the this answer do not answer the OP question, but well, it solved my problem. – Jun 07 '17 at 11:20
-
-
@carloswm85 Because that would declare a field in an interface, which the language does not currently allow. – Geoff Sep 14 '22 at 07:41
Eric Lippert nailed it, I'll use a different way to say what he said. All of the members of an interface are virtual and they all need to be overridden by a class that inherits the interface. You don't explicitly write the virtual keyword in the interface declaration, nor use the override keyword in the class, they are implied.
The virtual keyword is implemented in .NET with methods and a so-called v-table, an array of method pointers. The override keyword fills the v-table slot with a different method pointer, overwriting the one produced by the base class. Properties, events and indexers are implemented as methods under the hood. But fields are not. Interfaces can therefore not contain fields.

- 922,412
- 146
- 1,693
- 2,536
-
1You provided the technical/actual name (v-table) to the concept of slots mentioned by Eric. Thank you for the detail Hans. – RBT Feb 01 '17 at 03:12
-
What would be the point of a v-table if interfaces are disallowed default implementations? This changes in C# 8.0, but that's beside the point. – Anthony Mar 11 '20 at 13:11
-
@Anthony Multiple `class` and `struct` types can implement the same `interface` type: so when a method has an `interface`-typed parameter the compiler (or runtime) needs a way to map each `interface` member method to an actual implementation function-address in memory, a vtable is a sensible way to achieve that. Another reason is because a derived classes can re-implement an interface (roughly equivalent to `overrides` for non-interface methods) which would also require a vtable. Only `static` and non-virtual methods can be entirely resolved _statically_ without vtables (or other techniques). – Dai Jul 19 '23 at 12:49
Why not just have a Year
property, which is perfectly fine?
Interfaces don't contain fields because fields represent a specific implementation of data representation, and exposing them would break encapsulation. Thus having an interface with a field would effectively be coding to an implementation instead of an interface, which is a curious paradox for an interface to have!
For instance, part of your Year
specification might require that it be invalid for ICar
implementers to allow assignment to a Year
which is later than the current year + 1 or before 1900. There's no way to say that if you had exposed Year
fields -- far better to use properties instead to do the work here.

- 303,634
- 46
- 339
- 357
The short answer is yes, every implementing type will have to create its own backing variable. This is because an interface is analogous to a contract. All it can do is specify particular publicly accessible pieces of code that an implementing type must make available; it cannot contain any code itself.
Consider this scenario using what you suggest:
public interface InterfaceOne
{
int myBackingVariable;
int MyProperty { get { return myBackingVariable; } }
}
public interface InterfaceTwo
{
int myBackingVariable;
int MyProperty { get { return myBackingVariable; } }
}
public class MyClass : InterfaceOne, InterfaceTwo { }
We have a couple of problems here:
- Because all members of an interface are--by definition--public, our backing variable is now exposed to anyone using the interface
- Which
myBackingVariable
willMyClass
use?
The most common approach taken is to declare the interface and a barebones abstract class that implements it. This allows you the flexibility of either inheriting from the abstract class and getting the implementation for free, or explicitly implementing the interface and being allowed to inherit from another class. It works something like this:
public interface IMyInterface
{
int MyProperty { get; set; }
}
public abstract class MyInterfaceBase : IMyInterface
{
int myProperty;
public int MyProperty
{
get { return myProperty; }
set { myProperty = value; }
}
}

- 182,639
- 35
- 285
- 343
Others have given the 'Why', so I'll just add that your interface can define a Control; if you wrap it in a property:
public interface IView {
Control Year { get; }
}
public Form : IView {
public Control Year { get { return uxYear; } } //numeric text box or whatever
}

- 1,289
- 1
- 14
- 13
A lot has been said already, but to make it simple, here's my take. Interfaces are intended to have method contracts to be implemented by the consumers or classes and not to have fields to store values.
You may argue that then why properties are allowed? So the simple answer is - properties are internally defined as methods only.

- 7,310
- 17
- 40
- 61

- 469
- 6
- 12
-
1If you need to access a member just make it a property and you'll be good. – Unome Sep 02 '16 at 16:57
Interfaces do not contain any implementation.
- Define an interface with a property.
- Further you can implement that interface in any class and use this class going forward.
- If required you can have this property defined as virtual in the class so that you can modify its behaviour.

- 7,310
- 17
- 40
- 61

- 3,358
- 9
- 34
- 48
Beginning with C# 8.0, an interface may define a default implementation for members, including properties. Defining a default implementation for a property in an interface is rare because interfaces may not define instance data fields.
interface IEmployee
{
string Name
{
get;
set;
}
int Counter
{
get;
}
}
public class Employee : IEmployee
{
public static int numberOfEmployees;
private string _name;
public string Name // read-write instance property
{
get => _name;
set => _name = value;
}
private int _counter;
public int Counter // read-only instance property
{
get => _counter;
}
// constructor
public Employee() => _counter = ++numberOfEmployees;
}

- 997
- 2
- 12
- 25
For this you can have a Car base class that implement the year field, and all other implementations can inheritance from it.
An interface defines public instance properties and methods. Fields are typically private, or at the most protected, internal or protected internal (the term "field" is typically not used for anything public).
As stated by other replies you can define a base class and define a protected property which will be accessible by all inheritors.
One oddity is that an interface can in fact be defined as internal but it limits the usefulness of the interface, and it is typically used to define internal functionality that is not used by other external code.

- 193
- 5