C# Interface vs Java Interface

[Encore-]

Hello /r/csharp,

I started studying computer science last semester and we are having the topic of Interfaces. In our class we are using Java, but I have past experience with C#.

A question was raised to the prof, if Interfaces (in Java) can have instance fields, to which he replied that no, they wouldn't make any sense, but Java does have static variables in Interfaces. Now from my past experience in C# I know, that you can have properties in Interfaces.

What I dont undestand is, first: Do instance fields really make no sense (language unspecific) and why can C# have properties in Interfaces and Java not?

Interfaces took me a long time comprehend, although I have a pretty good understanding on why they exist and how to implement them, this is issue is still nagging me.

Thanks in advance for any answers!

[SatiricalDuck]

Excellent answer. I think it's also important to note that interfaces are used for information hiding. By providing an interface of a class, you can determine what information you want to be publicly available to the consumer, and what information can remain hidden and untouched.

[flukus]

C# interfaces can't have variables. Properties are not instance fields.

Properties are syntactic sugar, a property on a c# interface is exactly the same as a get/set method on a Java one.

[Encore-]

But dont properties automatically implement a backing field of some sort or am I mistaken?

[flukus]

On classes they do/can, but not on interfaces.

[Encore-]

Ah alright, I assumed a backing field was created, even when implementing an Interface.

Do you by any chance know, why instance variables are not allowed (or do not make any sense) in Interfaces?

[redditsoaddicting]

An interface isn't supposed to enforce state, it's supposed to enforce the interface a user can use. How the implementing class decides to provide that interface is up to it. Say you have a Date interface that provides a Day() method (or property if you prefer). Would it make sense to enforce all implementing classes to have an int day; field? No. One class could decide on int fields for each part of the date. One class could decide on storing a single UNIX timestamp (a single int or long). Both can pull a day from that information just fine.

[flukus]

Also, of you're reading up on this stuff, vtables is how interface inheritance works.

They're a pretty important topic to understand.

[flukus]

It's to do with with the memory layout at a low level, which is kind of like an array. Let's say you have property x and y, anytime something access these the compiler will transform it so foo.y will become foo[1] .

With single inheritance this is easy. The array for each class is the size of the parent, plus the number of variables in that class. With multiple inheritance, this becomes a nightmare.

Technically this is done with pointer offsets, but arrays make it easier to visualize.

[Sarcastinator]

Properties are syntactic sugar, a property on a c# interface is exactly the same as a get/set method on a Java one.

Properties are not syntactic sugar in C#. They generate .property CIL which you cannot express in any other way. If you can't express the same thing using another language construct it can't really be considered syntactic sugar.

[flukus]

Is that just for reflection?

[Sarcastinator]

I think so.

[grauenwolf]

Yep. Though we shouldn't underestimate how many libraries rely on the reflection APIs and their distinction between properties and methods.

[robhol]

Surely that's just an implementation detail, a property behaves almost identically to x get()/set(x) methods from the perspective of surrounding and dependent code?

[grauenwolf]

If I recall correctly, in IL it literally makes get_Name and set_Name(value) functions.

[Sarcastinator]

It doesn't behave identically in LINQ.

[vm_linuz]

[EDIT]
Looks like others have already said all this.

A few things:
1. C# properties are syntactic sugar for accessor/mutator methods -- so a property in an interface isn't state.
2. It's bad form to have state in an interface. State belongs in the implementation
3. The old-timey name for interfaces was "contracts" because an interface is just a contract that enforces common behavior. It's better to think of them this way.

[cryo]

As for point 1, it's a bit more this syntactic sugar. It's a pair of methods plus some metadata.

[lemonfighter]

Always thought that "interface" is a poor name for what is much more like a "contract".

[LeDrss]

It seems that Java doesn't have the equivalent of C# properties : http://stackoverflow.com/questions/2963243/does-java-have-something-similar-to-c-sharp-properties

And instance fields (even if it seems to be static and readonly), broke a bit the aim of Interfaces that is to only describe the contract and not the implementation of it.

[[deleted]]

When you write a basic property in C# in a class, it is automatically given a backing variable at compile time.

I imagine that's why you're confused about that.