Как мне организовать авторитетный код? - PullRequest
2 голосов
/ 15 марта 2010

У меня есть пользователи, которые попадают в следующие

  • Не авторизован
  • Не проверено
  • Проверенные
  • Модератор
  • Администратор

Весь код, к которому имеют доступ только администратор и модераторы (например, бан), находится в ModeratorUser, который наследует от Verified, который наследует от BaseUser. Некоторые страницы доступны всем пользователям, например общедоступные профили. Если пользователь вошел в систему, он может оставить комментарий. Чтобы проверить это, я использую if (IsVerifiedUser). Теперь вот проблема. Чтобы избежать проблем, если пользователя забанят, он не будет признан проверенным пользователем. Однако в редком случае мне нужно знать, если он проверен, я могу использовать usertype & Verified.

Разве я не должен этим заниматься? У меня есть куча кода в моем классе VerifiedUser, и я обнаружил, что перевожу его в BaseUser. Это то, что я помогаю, потому что не авторизованный пользователь может получить доступ к странице? Должен ли я обработать пользователя бана другим способом и позволить IsVerifiedUser быть истинным, даже если пользователь забанен?

1 Ответ

2 голосов
/ 16 марта 2010

По крайней мере, на мой взгляд, большинство подобных ситуаций должны обрабатываться в данных, а не в коде. Жесткое кодирование того факта, что (например) операция X может быть выполнена только администратором, имеет тенденцию быть относительно хрупким. Прямо сейчас у вас есть пять классов пользователей, но (только для примера) вы почти неизбежно (где-то вдоль линии) в конце концов придумаете какой-то другой класс пользователей, и вам придется реорганизовать совсем немного кода, чтобы соответствовать ( например, новый шаг на полпути между модератором и администратором, или, возможно, «пользователь с ограниченными правами», который на шаг ниже обычного проверенного пользователя, и т. д.) Фактически, вы уже в основном сталкиваетесь с этим «забаненным» пользователем, который в основном похож непроверенный пользователь, но в некоторых отношениях похожий на проверенного пользователя.

Необходимость переписывать код каждый раз, когда вы принимаете решение о таком изменении, - плохая идея. Вместо этого вы должны (вероятно) заранее определить свои пять (или, может быть, шесть) групп пользователей и (например) назначить бит каждой из них. Аналогично, назначьте битовую маску для каждой функции. Чтобы проверить, может ли данный пользователь выполнить данную функцию, вы И эти битовые маски вместе, и посмотрите, есть ли у пользователя соответствующие биты, установленные в его маске.

Это значительно упрощает создание новых групп по мере необходимости и / или изменение назначения прав для выполнения определенных функций для групп пользователей. В частности, он позволяет вносить изменения в такие права в административном порядке, а не требовать переписывания кода.

...