4

私はこれを見ています：

public interface IAjaxCallbackEventHandler : ICallbackEventHandler
    {
        string CallbackResponse { get; set; } 
    }
}

したがって、ページはこのインターフェイスを実装し、最終的に次のようになります。

public partial class XPage : Page, IAjaxCallbackEventHandler {
    // public because it's an interface, but really an implementation detail ;-(
    public string CallbackResponse { get; set; }

    // implementing underlying ICallbackEventHandler interface
    public void RaiseCallbackEvent(string eventArgument)
    {
        try
        {
            CallbackResponse = SomeOperation(eventArgument);
        }
        catch (Exception ex)
        {
            CallbackResponse = ex.ToString();
        }
    }

    // implementing underlying ICallbackEventHandler interface
    public string GetCallbackResult()
    {
        return CallbackResponse;
    }

}

私が知る限り、このインターフェースは、プログラマーがからの応答を保存して、RaiseCallbackEvent後でへの呼び出しから返されることを考えなければならないことを単に保証しGetCallbackResultます。

あなたはすでにこれを行う2つの方法を実装して考えなければならないので、私はこのテクニックの本当の利点を見ることができません。

あなたの考え-このアプローチの有効な利点はありますか、それとも単にコードの臭いですか？

4

1 に答える 1

2

インターフェイスはコントラクトを定義するだけであり、コントラクトの要件を満たす以外に、コードの実装方法を暗示するために依存するべきではありません。

特定のコード パスを暗示したい場合は、インターフェイスを実装し、それを継承する基本クラスを使用することをお勧めします。基本クラスでは、コードの流れをある程度制御しながら、オーバーライドされるロジックのカスタム ビットのエントリ ポイント。

于 2011-05-09T22:06:35.983 に答える