Войти или зарегистрироваться
  • Вы находитесь в сообществе Rubukkit. Мы - администраторы серверов Minecraft, разрабатываем собственные плагины и переводим на различные языки плагины наших коллег из других стран.

Помогите Command Handler

Быдло код?

  • 100%

  • 80%

  • 60%

  • 40%

  • 20%

  • Идеал = 0%


Результаты видны после голосования.

Smaylik03

Активный участник
Пользователь
Баллы
88
Имя в Minecraft
Alex_Wells
Здравствуйте. Пишу басис под плагины, написал вот хандлер комманд.. быдлокодерский, знаю, по этому и пишу, может кто-то сможет это понять и указать ошибки.. вот проект:
https://github.com/autaut03/BasePlugin
Путь: net.alexwells.baseplugin.handlers.commmand

Больше кроме как на хандлер не смотрите, ибо там полный пипец.
 
Сам недавно написал такого рода абстракцию...
А потом выкинул ее.
 
И? Вы думаете, что я про switch не знал? Смысла мне от него, если все равно получится не красивый, не читабельный код?
Вот такое, тоже не очень выглядит:
Java:
@CommandHandler(
cmd="test",
args="arg1 [onplayer:Player] arg2 [string:Lol] [string:Lol2]",
desc="Test command 1",
perm="baseplugin.commands.test")
public void func1(CommandSender sender, Command cmd, String label, String[] args) {
sender.sendMessage("Hi 1: " + args[1] + " | " + args[3] + " | " + args[4]);
}

Обычно такие вещи невозможно улучшить, это надо принять "как есть".
 
В обозримое нынешнее время тоже интересуюсь более красивой обработкой команд.
Пока костыли получаются наижесточайшие. Самый страшный код в плагине, остальное уже по-божески получилось.

Может кто подскажет Good Practice?
 
В обозримое нынешнее время тоже интересуюсь более красивой обработкой команд.
Пока костыли получаются наижесточайшие. Самый страшный код в плагине, остальное уже по-божески получилось.

Может кто подскажет Good Practice?
Мое мнение - надо избавится от идиотской проверки через length, а там видно будет
Может кто подскажет Good Practice?
Вот хорошая мысль:
Можно реализовать методы аля
getPlayer(sender, args, index)
{
Проверка на размер и существование / онлайность игрока, и в случае не того размера / отсутствия игрока - вывод месседжа сендеру и прекращение выполнения через throw / return null
}
 
@Reality_SC
Мне моя традиция обращаться с командами уже не нравится. Всё никак ничего удобнее не придумаю.
 
Я бегло пробежался по твоим и уже понял, что мне они тоже не нравятся =)
Аннотации тоже как-то муторно; хз. Надо сесть и подумать, что же тут можно придумать удобного.
 
Мое мнение - надо избавится от идиотской проверки через length, а там видно будет

Вот хорошая мысль:
Можно реализовать методы аля
getPlayer(sender, args, index)
{
Проверка на размер и существование / онлайность игрока, и в случае не того размера / отсутствия игрока - вывод месседжа сендеру и прекращение выполнения через throw / return null
}
Ага, а у меня это происходит автоматом.
Я бегло пробежался по твоим и уже понял, что мне они тоже не нравятся =)
Аннотации тоже как-то муторно; хз. Надо сесть и подумать, что же тут можно придумать удобного.
Ввел анотацию - все, и пермиссия чекается, и аргументы хандлятся, проверяются, и ошибки подсказывает! Идеальная система =)
 
Хендлинг комманд как и конфиги это вообще больная тема, как ни делаешь всё равно гавно одно выходит. В итоге в конце забиваеш и просто уже ебашиш как быстрее.
 
Хендлинг комманд как и конфиги это вообще больная тема, как ни делаешь всё равно гавно одно выходит. В итоге в конце забиваеш и просто уже ебашиш как быстрее.
Не, я хочу все по феншую =)
В обозримое нынешнее время тоже интересуюсь более красивой обработкой команд.
Пока костыли получаются наижесточайшие. Самый страшный код в плагине, остальное уже по-божески получилось.

Может кто подскажет Good Practice?
Ну вот, у тебя костыль статический - под каждую команду свой код. А у меня все автоматически, и никакого args.lenght == 4
 
Понятно, ситуация похоже у всех
просто уже ебашишь как быстрее
, у меня с утра появилось некоторое соображение, что можно сделать, я попробую реализовать идею и покажу вам. Без аннотаций, другой вариант немного, более табличный :)

Пока я пишу код, частично опишу задумку для обсуждения:
  • Предлагается интерфейс с методом, реализация тела которого будет выполнять код нужной команды:
    Java:
    public abstract interface FairyCommand
    {
        public abstract void execute(CommandSender sender, FairyArgument[] args) throws CommandAnswerException;
    }
    . Почему так?: 1. Тип результата void — большая краткость кода. Возвращаемые текстовые строки должны быть выкинуты через исключение, а оно уже имеет несколько конструкторов для удобства. 2. Количество аргументов в массиве args всегда будет равно числу заявленных при регистрации аргументов — уходят проверки на null и .length.
  • Класс аргумента FairyArgument имеет методы isPresent (проверка на наличие, если он не обязательный), getType (вернёт один из типов аргумента, которые перечислены в отдельном enum), и методы get### для опередлённых типов, которые заранее распарсены. Например, для аргумента типа FairyArgumentType.PLAYER нужен вызов Player getPlayer(). Список аргументов передаётся при регистрации команды с помощью отдельного описания FairyArgumentDesc, в котором можно указать его название, необходимость (если необходимый аргумент не был введён, команда не будет выполнена, а sender получит корректное описание синтаксиса команды), и т.п.
 
Последнее редактирование:
Проверяю вот так, а логика в другом классе
Код:
        if (args.length == 1) {
            if (args[0].equals("cmdone")) {
                return new OnCmdOne().onCommand(cd, args);
            } else if (args[0].equals("cmdtwo")) {
                return new OnCmdTwo().onCommand(cd, args);
            } else {
                data.sendMessage("bla bla bla");
                return true;
            }
        }

public abstract boolean onCommand(ConfigData cd, String[] args)
 
Проверяю вот так, а логика в другом классе
Код:
        if (args.length == 1) {
            if (args[0].equals("cmdone")) {
                return new OnCmdOne().onCommand(cd, args);
            } else if (args[0].equals("cmdtwo")) {
                return new OnCmdTwo().onCommand(cd, args);
            } else {
                data.sendMessage("bla bla bla");
                return true;
            }
        }

public abstract boolean onCommand(ConfigData cd, String[] args)
И при каждой команде создавать экземпляр класса команды?
 

Поделиться этой страницей

Назад
Верх