2

次のようなユーザーがいます

  • ログインしていない
  • 検証されていない
  • 確認済み
  • モデレータ
  • 管理者

管理者とモデレーターのみがアクセスできるすべてのコード（禁止など）は、BaseUserから継承するverifiedから継承するModeratorUserにあります。一部のページは、公開プロファイルなど、すべてのユーザーがアクセスできます。ユーザーがログインしている場合は、コメントを残すことができます。これを確認するには、を使用しますif (IsVerifiedUser)。ここに問題があります。ユーザーが禁止された場合の問題を回避するために、ユーザーは確認済みユーザーとして認識されません。ただし、まれに、彼が確認されているかどうかを知る必要がありますusertype & Verified。

私はこれをするべきではありませんか？VerifiedUserクラスにたくさんのコードがあり、大量のコードをBaseUserに移動していることがわかりました。ログインしていないユーザーがページにアクセスできるので、これは私が助けてくれるものですか？禁止ユーザーを別の方法で処理し、ユーザーが禁止されている場合でもIsVerifiedUserがtrueになるようにする必要がありますか？

4

1 に答える 1

2

少なくとも私の意見では、このような状況のほとんどは、コードではなくデータで処理する必要があります。(たとえば) 操作 X は管理者だけが実行できるという事実をハードコーディングすることは、比較的脆い傾向があります。現在、ユーザーには 5 つのクラスがありますが、(たとえば) ほぼ必然的に (どこかで) 別のユーザー クラスを発明することになり、それに合わせてかなりの量のコードを再編成する必要があります (たとえば、モデレーターと管理者の中間にある新しいステップ、または通常の検証済みユーザーの下のステップである「制限付きユーザー」などです。未確認のユーザーですが、いくつかの点で確認済みのユーザーに似ています。

このような変更を決定するたびにコードを書き直さなければならないのは、よくない考えです。代わりに、(おそらく) 5 つ (または 6 つ) のユーザー グループを事前に定義し、(たとえば) それぞれにビットを割り当てる必要があります。同様に、各関数にビットマスクを割り当てます。特定のユーザーが特定の機能を実行できるかどうかを確認するには、これらのビットマスクの AND をとり、ユーザーがマスクに適切なビットを設定しているかどうかを確認します。

これにより、必要に応じて新しいグループを作成したり、特定の機能を実行する権利の割り当てをユーザーのグループに変更したりすることが非常に簡単になります。特に、コードの書き直しを必要とせずに、そのような権利の変更を管理者が行うことができます。

于 2010-03-16T03:15:50.003 に答える