6

私は通常、次のような EventAggregator で使用される Prism イベントを作成しています。

public class SomeEvent : CompositePresentationEvent<SomeEventArgs> { }

public class SomeEventArgs
{
     public string Name { get; set; }
}

しかし、同僚のコードを見ていると、次のようなことに気付きました。

public class SomeEvent : CompositePresentationEvent<SomeEvent>
{
     public string Name { get; set; }
}

私の最初の質問は、なぜこれがコンパイルされるのですか? まだ定義されていないクラスを実装しているようです。第二に、それはアプリケーションにまったく悪影響を及ぼしますか?

4

1 に答える 1

8

私の最初の質問は、なぜこれがコンパイルされるのですか?

違反していると思われる仕様のルールはどれですか?

まだ定義されていないクラスを実装しているようです。

ステートメントが正確であるかどうかを判断するには、これらの各用語の正確な意味を指定する必要があると思います. コンパイラーはCompositePresentationEvent、それが他の場所で宣言されていることを認識しており (おそらく)、それが宣言されSomeEventているクラスであることを認識しています。クラス内にタイプのフィールドを持つようなものです - 完全に有効です。FooFoo

これを実行できることも非常に便利です- 特に比較のために。例えば：

public sealed class Foo : IComparable<Foo>

クラスのインスタンスはFoo、それ自体を別のインスタンスと比較する方法を知っているため、タイプセーフな方法でソートに使用できると言います。構造体の場合、適切に実装される型であることがわかっているx.CompareTo(y)場合、呼び出しでボクシングが不要になるため、ボクシングを減らすこともできます。xIComparable<>

型は、はるかに興味深く、紛らわしいほど再帰的になる可能性があることに注意してください。Protocol Buffers の私のポートから、この (少し変更された) 例を取り上げます。

public interface IMessage<TMessage, TBuilder>
    where TMessage : IMessage<TMessage, TBuilder>
    where TBuilder : IBuilder<TMessage, TBuilder>

public interface IBuilder<TMessage, TBuilder>
    where TMessage : IMessage<TMessage, TBuilder>
    where TBuilder : IBuilder<TMessage, TBuilder>

ここでの目的は、基本的に "メッセージ" と "ビルダー" の 2 つのタイプで終わることであり、いつでも相互に構築できるようになっています。例えば：

public class Foo : IMessage<Foo, FooBuilder>
{
    ...
}

public class FooBuilder : IBuilder<Foo, FooBuilder>
{
    ...
}
于 2012-05-22T19:50:07.513 に答える