web-dev-qa-db-ja.com

C#がインターフェイスのプロパティを許可するのはなぜですか?

C#では、次のコードが有効です

interface I{
    int property{get;set;}
}

これは私には意味がありません。これは、インターフェースの最も重要な原則の1つである状態の欠如(つまり、フィールドなし)を壊すようです。プロパティは暗黙のプライベートフィールドを作成しませんか?それはインターフェースにとって本当に悪いことではないでしょうか?

混乱する部分は、あなたがint Property { get; set; }クラス内では、暗黙のバッキングフィールドを持つ自動プロパティです。

しかし、インターフェイスでまったく同じことを記述した場合、自動プロパティではありませんは、プロパティがインターフェイスの一部であり、インターフェイスを実装するすべての型がそのプロパティを含む必要があることを宣言するだけです。 (自動プロパティとしてかどうか)、しかしそれはバッキングフィールドを作成しません。

違いを確認する1つの方法は、int Property { get; }:これはインターフェースで有効であり、getterのみを持ち、setterを持たないプロパティを宣言します。ただし、自動プロパティはセッターを持っている必要があるため、C#6.0を使用している場合を除き、クラスではコンパイルされません。

67
svick

ここまでに示したプロパティの定義は、メソッドint GetProperty()およびvoid SetProperty(int i)の定義と同じです。プロパティは、C#では強力な省略形です。

プロパティは、C#で暗黙的にプライベートフィールドを作成しません。これはauto-propertyのデフォルト実装です(例:public string MyString { get; set;})。ただし、getメソッドでカスタムロジックを定義するプロパティは、暗黙的なプライベートフィールドを生成しません。

最後に、インターフェイスはpublic APIに関係しているので、インターフェイスプロパティの実装がプライベートフィールドに依存している場合、何が問題になるでしょうか?それは関係なく、インターフェースの消費者から隠されています。

20
NWard

プロパティareメソッド!クラスにバッキングフィールドが追加され、インターフェースを実装します(手動または自動プロパティを介して)。

10
Roman Reiner