- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
public boolean alwaysAllowed(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.alwaysAllowed");
}
public boolean remoteAccess(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.remote");
}
public boolean canUse(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.use");
}
public boolean canInvite(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.caninvite");
}
public boolean infiniteHomes(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.infinite");
}
public boolean noWarmup(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.nowarmup");
}
public boolean noCooldown(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.nocooldown");
}
public boolean freeSetHome(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.freesethome");
}
public boolean freeHome(String player) {
return getServer().getPlayer(player).hasPermission("over9000homes.freehome");
}
Follow us!
Тем более эти функции судя по названиям не проверяют права как таковые, вот если бы они например назывались hasInvitePermission, то другое дело. А так результат функции canInvite помимо наличия права у player может зависеть от других параметров.
Я бы оставил вашу функцию и поместил ее вызов во все остальные, ну и конечно изменил бы названия некоторых функции на более говорящие, в частности бы добавил к ним can, как сделано у canInvite, хотя может для меня они не говорящие из-за того, что я не владею предметкой проекта
У вас везде по коду будут вызовы hasPermission(player, "caninvite") вроде все хорошо, но допустим в последующем потребуется изменить логику определения имеет ли игрок возможность делать инвайт (canInvite), скажем это будет еще зависеть от какого-либо атрибута игрока и вам придется ходить по всему коду и менять логику: hasPermission(player, "caninvite") && player->needAttribute
Вынеся все это в отдельные методы вы избавите себя от возможного геморроя, Также мне кажется что будет неплохо разнести эти функции и функции проверки прав по разным классам. Еще раз смотря на выложенный код, я думаю, что вашу функцию я поместил бы в другой класс и использовал ее внутри этих методов
Вариантов может быть много, Permission может быть интерфейсом с множеством реализаций и т.п. Мне такой вариант представляется более расширяемым.
Вы предлагаете инкапсулировать все эти знания в одной функции, а я в одном классе
fixed
Но если мы говорим о классе для проверки доступности какого-либо действия для пользователя то в принципе выложенный код нормален.
Привилегия есть а возможности нет.
Иначе не предоставляем никаких возможностей, либо не предоставляем возможностей редактирования темы, а, например, перемещение и удаление в соответствии с привилегиями.
Говоря короче - отталкиваться в первую очередь от состояния темы. А уж потом от привилегий пользователей.
Это всего лишь предположение. Я жеж студентота xD
А по теме вашего коммента, если я вас правильно понял, то большой разницы не вижу, напишите вы так
или вот так
У нас шла речь маленько о другом, что выложенный в топике код имеет право на жизнь и что в одном случае он может быть и говном, а в другом нет. Я попытался показать ситуацию когда этот по моему мнению не будет ГК.
тема открыта:...проверка привилегий...
тема закрыта:...проверка привилегий...
проверка привилегий не зависящих от состояния темы
Как-то так. Мне интересно послушать чужое мнение пока я не начал в учебных целях писать движок форума с помощью технологии JSP.
Мужчина заходит в бар и заказывает стакан виски и шесть соломинок, соединяет соломинки в одну и через эту длинную соломинку начинает пить виски. Бармен недоуменно спрашивает:
- Почему вы так делаете?
- Мне доктор велел держаться подальше от спиртного.