Jawa / Говнокод #8177 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 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");
	}

Всё тот же Bukkit проект.

Запостил: Uhehesh Uhehesh, (Updated )

Комментарии (39) RSS

  • ava roman-kashitsyn # Ссылка на оригинал 0 

    public boolean hasPermission(String player, String permission) {
    return getServer().getPlayer(player).hasPermission("over9000homes." + permission);
}
    fixed?
    Ответить

    • ava Byte # Ссылка на оригинал 0 ⇈

      Ваша функция гуд,но чем плохи функции обертки для каждого отдельного права ?
      Тем более эти функции судя по названиям не проверяют права как таковые, вот если бы они например назывались hasInvitePermission, то другое дело. А так результат функции canInvite помимо наличия права у player может зависеть от других параметров.
      Я бы оставил вашу функцию и поместил ее вызов во все остальные, ну и конечно изменил бы названия некоторых функции на более говорящие, в частности бы добавил к ним can, как сделано у canInvite, хотя может для меня они не говорящие из-за того, что я не владею предметкой проекта
      Ответить

      • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

        Порочна сама идея в принципе. Большое количество однотипных методов делает класс слишком статичным. Вероятность появления новых полномочий, судя по всему, довольно велика, потому имеет смысл сделать один метод, проверяющий полномочия, и отдельно иметь список всех возможных полномочий. Я бы выразил этот список в Enum'е (они специально спроектированы для дальнейшего расширения). Опять же, меньше будет проблем с сериализацией и прочими неочевидными вещами.
        Ответить

        • ava Byte # Ссылка на оригинал 0 ⇈

          С одной стороны я с вами согласен, но скажем вы удалили эти функции и оставили только свою hasPermission,

          У вас везде по коду будут вызовы hasPermission(player, "caninvite") вроде все хорошо, но допустим в последующем потребуется изменить логику определения имеет ли игрок возможность делать инвайт (canInvite), скажем это будет еще зависеть от какого-либо атрибута игрока и вам придется ходить по всему коду и менять логику: hasPermission(player, "caninvite") && player->needAttribute

          Вынеся все это в отдельные методы вы избавите себя от возможного геморроя, Также мне кажется что будет неплохо разнести эти функции и функции проверки прав по разным классам. Еще раз смотря на выложенный код, я думаю, что вашу функцию я поместил бы в другой класс и использовал ее внутри этих методов
          Ответить

          • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

            Если нужна более мощная функциональность, используем аналог паттерна Command: передаём в универсальную функцию специальный объект (если использовать Enum, для этого потребуются минимальные изменения, не затрагивающие клиентский код). Пример:
            public boolean hasPermission(String player, Permission p) {
    return getServer().getPlayer(player).hasPermission("over9000homes." + p) &&
p.applyConstraints(player);
}
            Вариантов может быть много, Permission может быть интерфейсом с множеством реализаций и т.п. Мне такой вариант представляется более расширяемым.
            Ответить

            • ava Byte # Ссылка на оригинал 0 ⇈

              Логика может быть разной и всю ее в одну универсальную функцию не поместишь, скажем если вам потребуется добавить возможность доступа на govnokod то логика может быть такой
              public boolean canAccessToGovnokod(String player) {
    return hasPermission(player, "accesstointernet") && player->isGoodMan && SomeGlobalStatesClass::canAccessAllUserToInternet
}


              Вы предлагаете инкапсулировать все эти знания в одной функции, а я в одном классе
              Ответить

              • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

                вообще-то я предлагал вынести каждое полномочие в отдельный класс / элемент енума, и помещать всю логику туда. А функция будет лишь фасадом для вызова соответствующей логики. Тогда появляется легко комбинировать полномочия по необходимости:
                //client code
Permission hasAccessToGK = Permission.Or(
        Permission.InternetAccess, Permission.GoodMan);
if (hasPermission("me", hasAccessToGK)) {
    sayWithPleasure("Fuck Yeah!");
}
                Ответить

                  • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

                    На самом деле в Java меня вполне устроил бы первый вариант. Java скорее останавливаем меня от описанного гибкого и типобезопасного подхода, нежели подталкивает к нему (больше букв получится, чем следовало бы для такой простой идеи).
                    Ответить

        • ava Byte # Ссылка на оригинал 0 ⇈

          Чтоб не было недопонимания, если мы имеем ввиду что это класс для проверки привилегий то ваш вариант идеален.

          Но если мы говорим о классе для проверки доступности какого-либо действия для пользователя то в принципе выложенный код нормален.
          Ответить

            • ava Byte # Ссылка на оригинал 0 ⇈

              Ну скажем вот вы находитесь на форуме, у вас есть привилегия писать в тему, но тема закрыта (в закрытые темы обычно не пишут).

              Привилегия есть а возможности нет.
              Ответить

              • ava SmackMyBitchUp # Ссылка на оригинал 0 ⇈

                В любом случае можно игнорировать привилегии в зависимости от состояния темы и прочего-прочего.
                Ответить

                • ava Byte # Ссылка на оригинал 0 ⇈

                  Поясните свой комментарий, я не до конца его понял
                  Ответить

                  • ava SmackMyBitchUp # Ссылка на оригинал 0 ⇈

                    Тема открыта: проверяем привилегий - предоставляем соответствующие возможности.
                    Иначе не предоставляем никаких возможностей, либо не предоставляем возможностей редактирования темы, а, например, перемещение и удаление в соответствии с привилегиями.

                    Говоря короче - отталкиваться в первую очередь от состояния темы. А уж потом от привилегий пользователей.

                    Это всего лишь предположение. Я жеж студентота xD
                    Ответить

                    • ava Byte # Ссылка на оригинал 0 ⇈

                      Возможно пример с форумом не самый удачный, но он был выбран что пояснить разниму между привилегией и возможностью выполнить действие, что это не одно и тоже.

                      А по теме вашего коммента, если я вас правильно понял, то большой разницы не вижу, напишите вы так
                      if (theme->isOpen) {
    canWrite  = hasPermission("write");
 }
 canDelete  = hasPermission("delete");


                      или вот так
                      canWrite  = hasPermission("write") && theme->isOpen;
    canDelete  = hasPermission("delete");


                      У нас шла речь маленько о другом, что выложенный в топике код имеет право на жизнь и что в одном случае он может быть и говном, а в другом нет. Я попытался показать ситуацию когда этот по моему мнению не будет ГК.
                      Ответить

                  • ava SmackMyBitchUp # Ссылка на оригинал 0 ⇈

                    То есть, в принципе будет 3 блока.
                    тема открыта:...проверка привилегий...
                    тема закрыта:...проверка привилегий...
                    проверка привилегий не зависящих от состояния темы

                    Как-то так. Мне интересно послушать чужое мнение пока я не начал в учебных целях писать движок форума с помощью технологии JSP.
                    Ответить

                    • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

                      Если вам интересно моё мнение, я бы использовал spring security и теги, которые он предоставляет. В результате получилось бы что-то вроде этого:
                      <sec:authorize access="hasRole('ROLE_USER')">
    <c:if test="${!theme.closed}">
        <button id="add-comment" value="Add a comment"/>
    </c:if>
</sec:authorize>
                      Ответить

                        • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

                          Только нужно не забыть на методы контроллеров @Secured('ROLE_USER') повесить и проверять внутри возможность добавления коммента. А то могут найтись умники, которые и без кнопки запостить смогут.
                          Ответить

                        • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

                          А вы таки хотите макет страницы на Java компоновать? Удачи. GWT в помощь.
                          Ответить

                            • ava roman-kashitsyn # Ссылка на оригинал 0 ⇈

                              Напомнило:
                              Мужчина заходит в бар и заказывает стакан виски и шесть соломинок, соединяет соломинки в одну и через эту длинную соломинку начинает пить виски. Бармен недоуменно спрашивает:
                              - Почему вы так делаете?
                              - Мне доктор велел держаться подальше от спиртного.
                              Ответить

  • ava guest # 0

    х(N:L?L$N)M)NK)J?GX"Y"A"P.T:R$C?T:Z?XG!H!B,S Y,X!N!G?B)Z$N!N(N.F(U$I?B K:S)O?W)D(S)E)S$P:M.H.Q.R:U$H V,Q.C!M,FIK!Z$Q(H.C$H.Q"D(V)Y"B.W"JH(O(A.T?R!X.D,LB$S.A,T:SW,C N Y.P$J!VI"G!K$W(E Y D$P)Y?P)V:X:F"O:K(Z?Y!Q!Z$P?S(K,R"X(N(D)EG,C?V"N:C!S:L"Q)F"Q$V"B!X(Z$M:O)N!T?Z R)M(A)VP:H"Q,II?E$HW,W$Z"W(TZ D)S.I.F(O.G)Q O$O:Z"G:KS"T"R Q:C N Z?F!F,N:M?F)V?B"Q!L.A(Z!B?F!C$K"T!B!J"F"O$D?V B X:K)H"F:Z(Q(M)K:N)G?DJQ!P!I:P(L$N:T:A!Q(R,M.B(Y?J(M)L(W(G?G(P$B,D"E:V)B S!L,O)I"I!W.I.KKY:D!P,T F I)P N(N.T)X)V)RG"F)G(D!Y S)N.A(BY)L D,Q!Q:E,F L$D B,D:I$I(O:W?D:V?PJOX)O!M F!H)B?X J!A?E!X)M$C:A,O?K KY"W(R!U!U.TP$U)Y!B?H?T"QB.T L!K(G)XKW)V.H F!Q$A!UB(G?FB.J!C:Q,C$L?I.J$F(W(M!Y!K(K?O H Q?DK,O V?U,C"CN,N!S)Q$R K?K)B(Q"G!T"T.FZ!W$KV(Q:O:R!N,T,M:H W.V"L)T(J$A(X.I U$R,H"L Q?Z?M$ON(C$G Z!I.T G$X:V)J Y:TWCYR F?G$V"S(R?B"D?W,RN)Q:Y$C)W,H:L$M$U:GM)N CF M J D,M"P?P L?X?J(O"B!M$P)Q"U!X!M"G"U.X$V?C$T$F"X!A.R S,K)J"C!UW)A)Q!GY!S)F:A:A"X,A,IK(Q"DY.F$S(K(V(D!T$I:I L?K(D(Y"E!A:C,O?D,C!Y?C!C)E D N.A!G(L)WV,H)A:G?MH$R!H?Q FN?H)W"R,R Z!Q?N)V(Y(E V?C!D)L.C.M$Z$B(M,T.B D!D$B:X)ZA(V"C)I V Q.N"RQ(H?X)W)B$I!X$TG!LO)W"S:I?S?T G,G.V(W(V S,A)H"B)O!U.P$D(I!E.C RH$N!B)A!U,Z.O I,TK(J.R:I$E,I?N:E:P,O$P$WQ(H)Q"W$R.RJ?D$H,H$QO?Q!Y,L(S(G!G$U)D.O"Z,R)X!H)M"C G)MWОUZKGOHYTJWZOYBIDQQPPLHYMCXOIJVCUZWASBPYGHDKRERPFETMGAQMZXAIEPQNNRMHUQVDJOSYVJLAQLWQTQWLTEIFITIUGMHIOIBKSFOTSUMCBITBVNRCLXMOLBUZIZDTCVCTUTNPXHXRAENODEMGCBLDDWMJEYHXXWNZXSUPSVLERGCKJVBFHTOGAEDNDWZYYDRESJQKZYYBZLFLAZVADEAMJYPPYUECFICTNCMNNQHXIUBYC
    Ответить

Добавить комментарий

Из-за тебя ушел bormand, guest!

    А не использовать ли нам bbcode?

    ↑
    8
    ↓