views:

159

answers:

7
+13  A: 

You're operating on a somewhat faulty assumption, that properties require a backing field. Yes most properties use a backing field but this is certainly not a requirement. I can for instance implement your interface with no backing field as follows

class C1 : IFoo {
  public string SayHello {
    get { return "Say Hello"; }
    set { }
  }
}
JaredPar
@Downvoter, care to give a reason?
JaredPar
Probably competitive.
Skurmedel
It is clear now.Thanks
+6  A: 

The declaration of a property in an interface says that any implementing class must have such methods (get_SayHello and set_SayHello but defined as properties) but does not specify how they are implemented. That is, the interface says what you can do, but now how it is done (so you can get the SayHello "string", and you can set the SayHello "string"). So, to be specific: defining a property in an interface says nothing about backing fields.

Also, it is a misconception that properties have to have backing fields. The following does not:

class Example {
    public string SayHello {
        get {
            return "Hello, World!"; 
        } 
        set { }
    }
}

Properties are just methods that are accessible via field-like syntax. As they are methods, and not fields, they are defineable an interface.

Jason
+2  A: 

My question is still property needs some storage location

That is not true. You can do whatever you want in getters/setters. By declaring a property in an interface, you just force implementers to provide a getter and/or a setter.

Romain Verdier
+1  A: 

Well a declaration inside an interface just tells you what members can be expected to exist on an instance of that interface. It tells you nothing about how they are implemented or where they are saved.

I think you have confused the concept of a interface with that of a class. You don't instantiate interfaces, but classes that implement them.

Skurmedel
+3  A: 

As Jared says, the property doesn't necessarily need any storage location... but you're still overthinking it, I believe.

Imagine your interface was actually:

public interface IFoo
{
   string get_SayHello();
   string set_SayHello(string value);
}

Just methods in an interface. Are you happy with that? If so, that really is all the property is, along with a bit of metadata to tie those methods together. Nothing to do with fields... just methods.

The implementer might want to use a field, but that's entirely separate from the interface.

Jon Skeet
+2  A: 

Declaring such a property in an interface simply means that any classes you define that implement the interface are required to implement that property. Those classes are free to implement the property in any way you see fit (either as automatic properties, or through some other more complex means).

Changing your property in the interface to the following:

string SayHello { get; }

The implementing classes are only required to implement the getter for that property. But no storage allocation is taking place at the interface level.

Skinniest Man
+2  A: 

Not all .NET languages have the concept of properties. So the interfaces must also define get_ and set_ versions of the property so that any .NET language can use the type. This might be adding to your confusion.

Will