In C #, il seguente codice è valido
interface I{
int property{get;set;}
}
Che non ha alcun senso per me. Questo sembra spezzare uno dei principi più importanti delle interfacce: la mancanza di stato (in altre parole, nessun campo). La proprietà non crea un campo privato implicito? Non sarebbe davvero male per le interfacce?
Penso che la parte confusa sia che se scrivi int Property { get; set; } all'interno di una classe, allora si tratta di una proprietà automatica con campo di applicazione implicito.
Ma se scrivi esattamente la stessa cosa in un'interfaccia, allora non è auto-property , semplicemente dichiara che la proprietà è parte dell'interfaccia e che qualsiasi tipo che implementa l'interfaccia deve contiene quella proprietà (come proprietà auto o meno), ma non crea il campo di supporto.
Un modo per vedere la differenza è scrivere int Property { get; } : questo è valido in un'interfaccia e dichiara una proprietà che ha solo un getter, ma nessun setter. Ma non verrà compilato in una classe (a meno che tu non stia utilizzando C # 6.0), perché la proprietà automatica deve avere un setter.
Definire la proprietà come hai mostrato è come definire i metodi int GetProperty() e void SetProperty(int i) . Le proprietà sono potenti abbreviate in C #.
Una proprietà non crea implicitamente un campo privato in C #. Questa è l'implementazione predefinita di auto-property , ad esempio public string MyString { get; set;} - tuttavia, una proprietà che definisce la logica personalizzata nel metodo get non genera un campo privato implicito.
Infine, poiché le interfacce riguardano l'API public , che importanza avrebbe se l'implementazione di una proprietà dell'interfaccia dipendesse da un campo privato, implicito o no? Questo è nascosto dai consumatori dell'interfaccia a prescindere.
I metodi sono ! Un campo di supporto verrà aggiunto alla classe che implementa l'interfaccia (manualmente o tramite una proprietà automatica).
Leggi altre domande sui tag c# interfaces properties