EventArgsまたは単純なデータ型を使用する必要がありますか？

Question

私は現在、楽しく実践のためのライブラリを作成しています。イベントを呼び出すときには、独自のEventArgs派生かデータ型を渡すかを選択する方法が不思議でした。このための標準的な方法である何

public delegate void LostConnectionEventHandler(string address); 
public delegate void MessageReceieved(byte[] bytes); 

：たとえば、私のライブラリで、私はこのような何かを

がありますか？ string addressをConnectionEventArgsと置き換え、byte[] bytesをMessageEventArgsと置き換えてください。

どちらもうまくいきますが、この質問は主観的かもしれませんが、自分のEventArgsを含めるかどうかを決定する際に、あるいは直接データを渡すかどうかを判断する上で、 。

ありがとうございます！

Answer 1

イベントに関する追加情報。 "e"パラメータの型は、EventArgsクラスから派生する必要があります。どのような追加情報も使用しないイベント の場合、.NET Frameworkには に適切なデリゲートタイプEventHandlerが既に定義されています。

参考：http://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx

別の有用な情報：あなたは、ステータス情報および集計オブジェクトを渡す必要があれば、簡単に行うことができhttp://msdn.microsoft.com/en-us/library/ms229011.aspx

Answer 2

私のプロジェクトでは、パラメータの数が1より大きい場合にEventArgsを使用しています。 NotifyPropertyChangedイベントを見ると、EventArgsタイプではない1つの引数があります。

Answer 3

EventArgsから派生する必要はありませんが、規約は一般的な（Introduce Parameter Object）リファクタリングルールに従います。そして、この規則の根拠は十分に文書化されている。 .NET Frameworkのガイドラインは イベントに使用されるデリゲート型は、2つのパラメータ、イベントのソースを示す「オブジェクトソース」パラメータ 、及び は、任意のカプセル化「E」パラメータを取るべきであることを示す

Answer 4

個人的に私は、EventArgs由来のアイデアのよう

たとえば、

MouseEventArgsのタイプを参照してください。

OOPアプローチを使用すると、タイプEventArgsのオブジェクトを受け入れるイベント/コンストラクトがある場合、それから派生するすべてのオブジェクトが同じ方法で動作するという事実に頼ることができます。同じ基本クラスを共有していないと、結局何かを壊す可能性があります。設計に応じ

証明し、再現するのは難しいが、可能

、イベントがいるEventArgsクラスを持つ、特別なEventArgsで動作するように設計された代表者と大規模プロジェクトでその子孫

Answer 5

ているので、あなたが持っているコードを最小限に抑えることに役立ちます場合によってはイベントに追加データが必要なときに変更することができます。私は通常、直接値の代わりにEventArgsの方法を優先します。