1

私には少しジレンマがあります。多分あなたは私を整理するのを手伝ってくれるでしょう。

私は今日、ASP.NETのメンバーシップを変更して、間接参照のレベルを追加することに取り組んでいます。基本的に、ASP.NETのメンバーシップはユーザーとロールをサポートし、すべての承認ルールはユーザーがロールに属しているかどうかに基づくようにします。

私がする必要があるのは、ユーザーが1つまたは複数のロールに属し、ロールに1つ以上の関数が関連付けられ、ユーザーが属しているかどうかに基づいて特定のアクションを承認できるようにする、関数の概念を追加することです。機能が割り当てられている役割に。

そうは言っても、私の問題はそれとは何の関係もありません。それはジェネリッククラスの設計の問題です。

基本のRoleProviderクラスに抽象メソッドを提供して関数を作成（および永続化）したいのですが、その関数の説明を保存することをオプションにしたいので、オーバーロードを使用してCreateFunctionメソッドを作成する必要があります。名前を受け入れる署名、および名前と説明を受け入れる他の署名。

私は次のシナリオを考えることができます：

  1. 抽象修飾子を使用して両方の署名を作成します。これには、実装者が、一方のオーバーロードがパラメータを正規化してもう一方を呼び出す必要があり、ロジックは最後の1つ（すべてのパラメータを含むもの）にのみ存在する必要があるというベストプラクティスを尊重しない可能性があるという問題があります。さらに、開発者が両方のメソッドを実装する必要があるのは良くありません。

  2. 最初のような仮想と2番目のような抽象を作成します。最初から2番目を呼び出し、実装者が動作をオーバーライドできるようにします。同じ問題があり、実装者はそれをオーバーライドするときに「悪い決定」をする可能性があります。

  3. 以前と同じですが、最初のオーバーライドを許可しないでください（仮想修飾子を削除してください）。ここでの問題は、実装者がメソッドがnull記述で呼び出される可能性があることを認識し、その状況を処理する必要があることです。

最良の選択肢は3番目の選択肢だと思います...

このシナリオは一般的にどのように処理されますか？抽象クラスを設計し、オーバーロードされたメソッドが含まれている場合。そんなに珍しいことではないと思います...

4

2 に答える 2

1

DRYnessと契約の強制の最良の組み合わせは次のように感じます（擬似コードで）：

class Base {
  public final constructor(name) {
    constructor(name, null)
  end

  public abstract constructor(name, description);
}

または、代わりに：

class Base {
  public abstract constructor(name);

  public final constructor(name, description) {
    constructor(name)
    this.set_description(description)
  }

  private final set_description(description) {
    ...
  }
}

Javaには、この決定をサポートするルールがあります。「コンストラクターから非最終メソッドを呼び出さないでください」。

于 2008-08-29T17:41:16.940 に答える
0

投稿の最初の部分に答えるには、Windows に組み込まれている AzMan (Authorization Manager) を確認してください。ロールに再結合したり、ユーザーに直接割り当てたりできる操作を指定する機能があります。

チェックアウト

あなたの質問の 2 番目の部分に答えるために、Abstract クラスは使用しません。代わりに、コンストラクターで機能を提供するだけで完了します。指定された動作が必要なように見えますが、それを変更したくありません。子孫に実装を提供するように強制する理由。

于 2008-08-29T18:42:31.490 に答える