2

クリックされたときに何かを実行する Windows フォームのボタンをイメージします。

発生するクリック イベントは通常、次のようなメソッドにバインドされます。

protected void Button1_Click(オブジェクト送信者, EventArgs e) {

}

他の人のコードで時々見られるのは、ボタンの動作の実装が Button1_Click メソッドではなく、次のようにここから呼び出される独自のメソッドに配置されていることです。

プライベート DoStuff() { }

protected void Button1_Click(オブジェクト送信者, EventArgs e) { this.DoStuff(); }

ここには利点がありますが (たとえば、このコードが別の場所で内部的に必要な場合、簡単に使用できます)、これが一般的に適切な設計上の決定であるかどうか疑問に思っています。

質問は次のとおりです。イベント処理コードを独自のメソッドに入れることは一般的に良い考えですか?もしそうなら、それらのメソッドのどのような命名規則がベストプラクティスであることが証明されていますか?

4

4 に答える 4

4

次の場合、イベント処理コードを別のメソッドに入れます。

  • コードは、複数のイベントによって、または他の場所から呼び出されるか、
  • コードは実際には GUI とは関係なく、バックエンドの作業に似ています。

小さなものや GUI 関連のみが常にハンドラーに入ります。同じイベントから呼び出された場合でも (シグネチャが同じである限り) ハンドラーに入ることがあります。つまり、それが一般的なアクションである場合は別のメソッドを使用し、メソッドが実際のイベントに密接に関連している場合は使用しないでください。

于 2008-10-01T11:59:57.993 に答える
2

経験則として、メソッドが何らかの UI 固有の処理を行っているか、実際に一般的なアクションを実装しているかを確認することをお勧めします。たとえば、臀部のクリック メソッドは、クリックを処理するか、フォームを送信することができます。前者の場合は、button_click ハンドラーに残しても問題ありませんが、後者の場合は独自のメソッドが必要です。私が言いたいのは、単一責任の原則を心に留めておくことです。

于 2008-10-01T11:58:56.183 に答える
1

この場合、DoStuff() メソッドを保持しますが、次のようにサブスクライブします。

button1.Click += delegate { DoStuff(); }

確かに、デザイナーですべてのイベントの配線を行う人には喜ばないでしょう... しかし、個人的には、そのほうが簡単に検査できると思います。(自動生成されたイベント ハンドラ名も嫌いです...)

于 2008-10-01T12:10:33.160 に答える
0

率直な答えはイエスです。他の場所で再利用するためだけでなく、OOP の観点からも、タスクを独自のメソッドにカプセル化するのが最善です。この特定のケースでは、ボタンをクリックするとプロセス呼び出し DoStuff が開始されます。ボタンはプロセスをトリガーしているだけです。Button1_Click は、DoStuff とは完全に別のタスクです。ただし、DoStuff はより説明的であるだけでなく、実行中の実際の作業からボタンを切り離します。

経験則として、メソッドが何らかの UI 固有の処理を行っているか、実際に一般的なアクションを実装しているかを確認することをお勧めします。たとえば、臀部のクリック メソッドは、クリックを処理するか、フォームを送信することができます。前者の場合は、button_click ハンドラーに残しても問題ありませんが、後者の場合は独自のメソッドが必要です。私が言いたいのは、単一責任の原則を心に留めておくことです。

次の場合、イベント処理コードを別のメソッドに入れます。

  • コードは、複数のイベントによって、または他の場所から呼び出されるか、

  • コードは実際には GUI とは関係なく、バックエンドの作業に似ています。

小さなものや GUI 関連のみが常にハンドラーに入ります。同じイベントから呼び出された場合でも (シグネチャが同じである限り) ハンドラーに入ることがあります。つまり、それが一般的なアクションである場合は別のメソッドを使用し、メソッドが実際のイベントに密接に関連している場合は使用しないでください。

于 2008-10-01T12:01:03.387 に答える