5

このことを考慮：

public class interface Person : IPerson
{
  int ID { get; protected set; }
  string FirstName { get; set; }
  string LastName { get; set; }
  string FullName { get { return FirstName + " " + LastName; } }
}

この：

public class StubPerson : IPerson
{
    int ID { get { return 0; protected set { } }
    string FirstName { get { return "Test" } set { } }
    string LastName { get { return "User" } set { } }
    string FullName { get { return FirstName + " " + LastName; } }
}

使用法：

IPerson iperson = new Person();

または：

IPerson ipersonStub = new StubPerson();

または：

IPerson ipersonMock = mocks.CreateMock<IPerson>();

したがって、事実上、IPersonインターフェイスとPersonクラスを同時に宣言しています。

public class interface Person : IPerson

.NET/C# でこの種のサポートがあれば便利だと思いますか?

編集：

大混乱のため、提案された目的を明確にする必要があると思います。

この機能がなければ、次のように記述する必要があります。

interface IPerson
{
  int ID { get; }
  string FirstName { get; set; }
  string LastName { get; set; }
  string FullName { get; }
}

これと同様に：

public class Person : IPerson
{
  int ID { get; protected set; }
  string FirstName { get; set; }
  string LastName { get; set; }
  string FullName { get { return FirstName + " " + LastName; } }
}

私はセマンティックの変更をまったく提案していません。

4

9 に答える 9

11

あなたが求めていることを理解しているかどうか見てみましょう：

インターフェイスを宣言できない理由:

interface IPerson
{
    string Name {get;set;}
    int ID {get;set;}
}

そして、そのインターフェースを実装するクラスは、それらを再宣言することなくそのプロパティを継承します:

class Person : IPerson { } 
//person now has properties Name and ID

これができない理由は、インターフェイス コードとクラス コードのテキストが非常に似ていても、意味が大きく異なるからです。インターフェースは単に「implementor は getter と setter を持つ文字列 Name を持つ」と言っています。「名前のゲッターが呼び出されたときにプライベートフィールドを返す」というクラスです。auto-property ショートカットを使用してコンパイラにそのロジックを実装させたとしても、クラスに属するのはlogicのままです。理由：

string Name {get;set;}

インターフェイスとクラスで同じように見えますが、リモートでさえ同じことを意味するわけではありません。

コントラクトを実装していないとコンパイル時に不平を言うのではなく、コンパイラが任意のロジックを実装してコントラクトを実行するのは非常に危険です。追跡が非常に困難なバグが発生する可能性があります。動作が定義されていないときにコンパイラをデフォルトの動作に戻すことは、非常に悪い考えです。

于 2009-03-18T00:53:30.497 に答える
4

私はしばらく前に同じようなことを考えました。特に、インターフェースのプロダクション実装が 1 つしかない場合に使用しますが、テストのためにそれをモックしたい場合に使用します。現時点では、昔の .c/.h ファイルに少し似ています。

最終的には、言語とその後のコードの読み取りの両方での余分な複雑さが、その利点を上回っているのではないかと思います。しかし、私はそれがより徹底的に調査されるのを見ることにまだ興味があります. それでも、私の優先リストには他にももっと高いものがあります-不変性のより良いサポートが一番上にあります:)

于 2009-03-18T06:25:41.933 に答える
1

少なくとも、私が要求した場合、Visual Studio がインターフェースから私のプロパティを自動プロパティとして実装することを望みます。

残念ながら、このオプションはそうではなく、実装されていない例外スタブに対処する必要があります

于 2009-04-08T14:11:14.327 に答える
1

私はポイントを逃していると思います-クラスとインターフェースを一緒に混合することによって何を達成していますか? このアプローチでどのような問題を解決していますか?

これ：

IPerson iperson = new Person();

C# ではすでに合法です。

編集：明確にするために-上記のコードは、次の場合に合法です：

interface IPerson { }

class Person : IPerson { }
于 2009-03-18T00:41:59.217 に答える
0

これのより良い抽象化は、特性、またはここで説明したように、役割だと思います。これは、コードとのインターフェースのようなものです。あなたの例は次のようにコーディングできます：

public role RPerson { 
  int ID { get; protected set; } 
  string FirstName { get; set; } 
  string LastName { get; set; } 
  string FullName { get { return FirstName + " " + LastName; } } 
} 

public class Person : RPerson { }

public class StubPerson : RPerson { 
    int ID { get { return 0; protected set { } } 
    string FirstName { get { return "Test" } set { } } 
    string LastName { get { return "User" } set { } } 
    string FullName { get { return FirstName + " " + LastName; } } 
} 

// ...

RPerson rperson = new Person(); 

RPerson rpersonStub = new StubPerson();
于 2010-11-01T13:35:34.767 に答える
0

いいえ、インターフェイスのすべてのパブリック メンバーを公開する必要があるためです。ReSharperを試してみてください。もうこれについて心配する必要はありません。

于 2009-03-18T00:52:49.207 に答える