これを行うには、OO であるいくつかの方法があります。
if( user->has_permission( REGISTER_STUDENT ) ) {
register_student();
}
これは、学生を登録する権限があるかどうかをユーザー インスタンスに尋ねています。別の方法:
if( user->in_role( ROLE_ADMIN ) ) {
register_student();
}
私がコードで抱えている問題は、管理者の役割がどのように決定されるかに関する内部の詳細が公開されていることです。この手紙a
は最終的には文脈を失い、新しいメンテナへのステータスとしては無意味になります。一方、定数ROLE_ADMIN
/REGISTER_STUDENT
は、追加のコメントを必要とせずにコードの意図を明確にします。
登録を実行するのは、実際にはUser
クラスまたはクラスの責任ではありません。aが自分自身を登録Admin
することは理にかなっています:Student
if( user->in_role( ROLE_ADMIN ) ) {
student->register();
}
Controller
このコードは、クラスで見られると予想されます。このController
クラスは、ユーザー インターフェイス オブジェクトを調べて、次のことを判断できます。
- 現在選ばれている生徒は
- ユーザーがインターフェースから選択したオプション
- ユーザーの役割
以下を実装できます。
if( user->is_admin() ) {
student->register();
}
コードは非常に明確ですが、次の可能性を残しておきたい場合があるため、柔軟性が低くなります。
if( controller->can_execute( user, action ) ) {
action->execute();
}
else {
controller->execute_error( user, action );
}
これにより、ロールをアクションに動的に割り当てることができるという点で、より柔軟なシステムが提供されます。たとえば、メソッドstudent->register()
を にマップできますROLE_ADMIN
。これにより、アプリケーション全体のすべてのセキュリティ制約が 1 つの場所に保持され、メンテナンスが大幅に簡素化されます。
さらに単純化することもできます。
controller->execute( user, action );
次に、execute メソッドは次のようになります。
void execute( User user, Action action ) {
if( can_execute( user, action ) ) {
action->execute();
}
else {
error( user, action );
}
}
bool can_execute( User user, Action action ) {
return user->is_in_role( action->get_role() );
}
アクセス許可エラーの表示方法 (ダイアログ ボックスとcout
) の実装の詳細が抽象化されました。さらに、次のようなより包括的なエラー メッセージが表示される場合があります。
"User registration is restricted to the administrator role."
次の文字列としてエンコードされます。
"%s is restricted to the %s role."
コントローラークラスは自動的に置き換えることができ%s
ます。