12

現在、イベント引数なしで定義されているイベントがあります。つまり、送信する EventArgs は EventArgs.Empty です。

この場合、イベント ハンドラーを次のように宣言するのが最も簡単です。

EventHandler<System.EventArgs> MyCustomEvent;

このイベントにイベント引数を追加する予定はありませんが、将来コードの変更が必要になる可能性があります。

System.EventArgsしたがって、現在必要なイベント引数がない場合でも、すべてのイベントで常に から継承される空のイベント引数タイプを作成することに傾いています。このようなもの：

public class MyCustomEventArgs : EventArgs
{
}

そして、私のイベント定義は次のようになります。

EventHandler<MyCustomEventArgs> MyCustomEvent;

したがって、私の質問は次のとおりです。イベント引数を将来より簡単に追加できるように、MyCustomEventArgsからの継承以外に何も追加しない場合でも、独自の を定義する方がよいでしょうか? それとも、追加のイベント引数がないことがユーザーに明確になるようにSystem.EventArgs、イベントを明示的に return として定義する方がよいでしょうか?System.EventArgs

イベント引数が空であっても、すべてのイベントに対してカスタム イベント引数を作成する方向に傾いています。しかし、イベント引数が空であることをユーザーに明確にする方が良いと他の人が考えているのではないかと思っていましたか?

よろしくお願いします。

マイク

4

2 に答える 2

14

Brad Abrams と Krzysztof Cwalina によるFramework Design Guidelinesから:

のサブクラスをEventArgsイベント引数として使用することを検討してください。ただし、イベントがイベント処理メソッドにデータを運ぶ必要がまったくないと確信している場合を除きます。その場合は、EventArgs型を直接使用できます。

直接使用して API を出荷する場合EventArgs、互換性を損なうことなく、イベントで運ばれるデータを追加することはできません。サブクラスを使用すると、最初は完全に空であっても、必要に応じてサブクラスにプロパティを追加できます。

個人的には、これは互換性の問題に帰着すると思います。他のユーザーが使用するクラス ライブラリを作成している場合は、サブクラスを使用します。独自のコードでのみイベントを使用している場合は、(Alfred が言ったように) YAGNI が適用されます。から独自の派生クラスに変更すると重大な変更になりますEventArgsが、独自のコードを壊すだけなので、それほど大きな問題ではありません。

于 2009-08-23T14:03:31.250 に答える
9

ヤグニ

EventArgs に固執し、本当に必要になったときにのみ別のものを使用することをお勧めします。

アップデート：

adrianbanksが指摘したように、あなたのコードがあなたの管理下にない他のコード (つまり、自分でコンパイルできないコード) によって消費される場合、または消費者コードの再コンパイルが面倒な場合は、EventHandler<YourEventArgs>を使用する必要があります。

于 2009-08-23T13:32:14.927 に答える