2012-05-29 17 views
24

インターフェイスが別のインターフェイスを返すプロパティまたはメソッドを指定している場合、最初のインターフェイスの実装で戻り値の型をより具体的な型に "変更"できないのはなぜですか?なぜインタフェース実装がより特定の型を返すことができないのですか?

がさんは説明するために例を見てみましょう:

interface IFoo 
{ 
    IBar GetBar(); 
} 
interface IBar 
{ } 

class Foo : IFoo 
{ 
    // This is illegal, we are not implementing IFoo properly 
    public Bar GetBar() 
    { 
     return new Bar(); 
    } 
} 

class Bar : IBar 
{ } 

私はを知ってそれを動作させるためにどのように、それはない私の懸念があります。

私はどちらかの可能

IBarからGetFoo()、または

    • 変更戻り値の型が明示的インターフェイスを実装し、ちょうど私が本当に求めています何

    IFoo.GetBar()方法からGetBarを呼び出します上記のコードをコンパイルするだけではない理由があります。上記がIFooで指定された契約を履行しない場合がありますか?

  • +1

    3つ目の方法があり、これは上記2つの方法よりも少し便利です。抽象クラスを使用してインタフェースを実装できます。そして、あなたの "具体的な"クラスでは、インターフェイスの代わりに抽象クラスを継承します。その後、あなたの "具体的な"クラスでは、 "新しい"キーワードを使って基本メソッドを隠すことができます。それは私にとってうまくいっている。 – BrainSlugs83

    +0

    私はBrainSlugs83のコメントがちょっとした解決策を提供してくれているように答えているように感じます。 –

    答えて

    17

    通常、私は、そのような機能をサポートすることの追加された複雑さと利益のバランスをとるケースであると言いたいと思います。 (すべての機能は、設計、文書化、実装、テストに努力し、開発者はそれらについても教育を受ける必要があります)。例えば、インタフェースを実装した値の型を返すことをサポートしたい場合は、 (それはちょうど参照ではなく、別の表現で終わる)。

    CLRはこのような機能もサポートしているため、C#がきれいに処理するのが非常に難しくなります。

    私はそれが有用な機能となることに同意しますが、余分な作業を保証するのに十分ではないと思われます。

    +7

    Jon質問がありますか?あなたは1分でどれくらい書くのですか? –

    +0

    +1は "...複雑さを増しました..."という点ですが、私はそれが有用であるとは本当に確信していません。すべてのインタフェースが契約の後に、そのようなメソッドが必要な場合は、明示的にインタフェースメソッドを実装し、_required_戻り型の別のメソッドを追加することができます。 –

    +1

    @Adriano:はい、できます。しかし、あなたがそうしなければならないのは面倒です。明示的なインタフェースの実装には、独自の弱点と複雑さがあります。私は可能な限り明示的なインターフェースの実装を避けています。共変な戻り値の型がサポートされていれば、避けることができる別の場所になります:) –

    3

    あなたがお尋ねしている機能は、「戻り値の共分散」と呼ばれています。 on Wikipediaと記されているように、JavaとC++の両方がそれを持っています。おそらく、C#はそれを驚かせるでしょう。

    Eric Lippertは、この回答のコメントで、この機能が実装されていないと判断したため、この機能が実装されていないことを確認しています。 (この回答の以前の改訂版は、個人的にこの決定に責任を負っていました;彼はこれが間違っていると言います。もし誰かが責任を負うなら、それはAnders Hejlsbergでした)。それは言語(https://github.com/dotnet/roslyn/issues/357https://github.com/dotnet/csharplang/blob/master/proposals/covariant-returns.mdhttps://github.com/kingces95/coreclr/issues/2を参照)にあるので、おそらくそれは今後数年以内に実装されるでしょう。これらの議論では、C#に機能が存在してはならない深刻な理由があるようには思えません。 - むしろ、実現しようとする人の価値があると判断されたことはありません。

    +3

    この機能は、C#デザインチームに参加する数年前にJavaに追加されたので、当時の私の意見は考慮されていませんでした。私がC#の設計チームにいる間、私の思い出しには、この問題は決して設計チームによって考慮されていませんでした。それゆえ、* Anders *は努力の価値があるとは思わなかったと言うのがより正確です。私はそれが悪い特徴だとは思わないし、C#がそれを持っていたらそれを使うだろう。私はもっ​​と優先順位を上げることができる多くの機能があることに同意します。 –

    関連する問題