Coder Perfect

Why can’t fields be used in C# interfaces?


The field Year will be included in the implementations. Does this imply that each implementation must specify Year separately? Isn’t it more convenient to just define this in the interface?

Asked by deltanovember

Solution #1

Though many of the previous responses are valid on a semantic level, I think it’s also useful to look at these topics from the perspective of implementation specifics.

An interface can be viewed as a collection of slots containing methods. When a class implements an interface, it must instruct the runtime how to fill in all of the necessary slots. If you say,

interface IFoo { void M(); } 
class Foo : IFoo { public void M() { ... } }

“Stuff a reference to Foo.M in the slot for IFoo.M when you create an instance of me,” the class says.

Then, when you make a call, say:

IFoo ifoo = new Foo();

“Ask the object what method is in the slot for IFoo.M, and call that method,” the compiler writes.

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. A field, on the other hand, is not the same as a technique. 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.

Answered by Eric Lippert

Solution #2

In C#, interfaces are used to establish the contract that a class will follow, rather than a specific implementation.

In similar vein, C# interfaces allow for the definition of attributes, for which the caller must provide an implementation:

interface ICar
    int Year { get; set; }

If there is no specific logic associated with the property, implementation classes can use auto-properties to make it easier to implement:

class Automobile : ICar
    public int Year { get; set; } // automatically implemented

Answered by LBushkin

Solution #3

Declare it as a property by using the following syntax:

interface ICar {
   int Year { get; set; }

Answered by Tarydon

Solution #4

Eric Lippert nailed it, and I’ll state it in a different way. An interface’s members are all virtual, and they must all be overridden by a class that inherits the interface. The virtual keyword is not explicitly written in the interface declaration, nor is the override keyword used in the class; both are presumed.

Methods and a so-called v-table, an array of method pointers, are used to implement the virtual keyword in.NET. Overwriting the one produced by the base class, the override keyword fills the v-table slot with an alternative method reference. Under the hood, properties, events, and indexers are implemented as methods. However, fields are not. As a result, fields are not permitted in interfaces.

Answered by Hans Passant

Solution #5

Why not just have a Year property, which would suffice?

Fields are not included in interfaces because they reflect a specific implementation of data representation, and exposing them would compromise encapsulation. As a result, having an interface with a field is effectively coding to an implementation rather than an interface, which is an odd dichotomy for an interface!

For example, part of your Year specification can include that assigning a Year that is later than the current year + 1 or before 1900 is invalid for ICar implementers. There’s no way to express that if you exposed Year fields — it’s significantly better to conduct the work with properties instead.

Answered by John Feminella

Post is based on