多くの Microsoft .NET クラスで、次のような非抽象/仮想パブリック メソッドがしばしば存在することに気付きました。
public bool MyAwesomeMethod(object someParameter);
そして、次のような保護された抽象/仮想メソッド
protected virtual bool OnMyAwesomeMethod(object someParameter);
私は最近、これが既知の設計パターンであるかどうか、およびそのような設計の長所と短所は何かと考え始めました。クラスの子が防止できないロジック (ロギングなど) を基本クラスが実行できるようにすることがすべてですか? 子クラスでオーバーライド可能にしたいことがわかっているメソッドに対して、デフォルトでこのソート設計を使用することは、何らかの理由で望ましくありませんか? 私が取り上げていない他の考慮事項はありますか？
よろしくお願いします。
それだけです。派生クラスのオーバーライドの前および/または後に何らかの動作を常に発生させたい場合に使用します。
ロギングは確かに可能ですが、時々行われるより低レベルの呼び出しではありそうにありません。ただし、クラスの操作に不可欠ないくつかのことの 1 つになる可能性があります。
また、後で必要になる前または後の各呼び出しのトラップが必要な場合に備えて、実行することもできます。通常の柔軟性 vs YAGNI 引数が適用されます。
MS WinForms/WPF コーディング規約では、"On" で始まる関数を使用してイベントを発生させます。これらのメソッドには、常にではありませんが、関連するパブリック メソッドがある場合があります。ほとんどの場合、関連するイベント デリゲートがあります。
この利点 (および欠点) は、関心の分離と、Windows GUI に固有のメッセージ パッシングに関係しています。基本的に、Control.Invalidate() などのメソッドを呼び出すときは、Windows メッセージ ループ (この場合は WM_PAINT メッセージ) を介してメッセージを自分自身に送信するようコントロールに指示することです。これはプログラムによって Windows にプッシュされ、アプリケーションが処理できるようにメッセージ キューのバックエンドに置かれます。このように、UI に関連するコマンドは FIFO 方式で処理され、アニメーションや UI への絶え間ない変更などは、UI スレッドのすべての時間を消費しません。
とにかく、プログラムのメッセージ ポンプが WM_PAINT メッセージをキューから戻すと、それをコントロールに送信し、コントロールは OnPaint() を呼び出して応答します。OnPaint() は、(通常は他のメソッドを呼び出すことによって) 基本的なコントロールの描画を行い、次に Paint イベントを発生させます。これは、コントロールが再描画されるときに何かを行う必要があるため、コードの他の部分がリッスンしている可能性があります。