Помогите Аргумент команды в отдельном классе как в Мини играх

[Energy warrior]

Я уже задавал вопрос на эту тему. Но те самые "азы Java" не работают.
Задам этот вопрос ещё раз.
Как распределить аргументы команды по отдельным классам. например есть команда /minigame у неё есть аргументы create,setminplayers,setmaxplayers как распределить их по классам?

 

[alexandrage]

Руками, ибо там идет массив с аргументами в методе.

 

[Energy warrior]

Руками, ибо там идет массив с аргументами в методе.

Да понятно что руками чем же ещё не ногами же(хотя такие индивиды существуют). Код,способ,статья,видео(на русском или нет)

 

[AtomicScience]

Можно создать 100500 классов со статическими методами и передавать в них твои аргументы, если первый аргумент соответствует create, setminplayers и т.д.
Вот только подумай, нужно ли тебе создавать отдельный класс для метода в 5 строчек?

И да, "азы Java" тут прекрасно работают

 

[Energy warrior]

Можно создать 100500 классов со статическими методами и передавать в них твои аргументы, если первый аргумент соответствует create, setminplayers и т.д.
Вот только подумай, нужно ли тебе создавать отдельный класс для метода в 5 строчек?

И да, "азы Java" тут прекрасно работают

Не в пять а в овер дофига. И способ немного не понятен

 

[alexandrage]

Не в пять а в овер дофига. И способ немного не понятен

        Map<String,IMyclass> mclass = new HashMap<String,IMyclass>();
        mclass.put("reload", new MyClass1());
        mclass.get(args[1]);
        IMyclass value = mclass.get(args[1]);
        value.onCommand(sender, cmd, label, args);

public interface IMyclass {
    public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args);
}

public class MyClass1 implements IMyclass {

    @Override
    public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args) {
        // TODO Auto-generated method stub
        return false;
    }
}

Сойдет?

 

[Energy warrior]

        Map<String,IMyclass> mclass = new HashMap<String,IMyclass>();
        mclass.put("reload", new MyClass1());
        mclass.get(args[1]);

public interface IMyclass {
    public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args);
}

public class MyClass1 implements IMyclass {

    @Override
    public boolean onCommand(CommandSender sender, Command cmd, String label, String[] args) {
        // TODO Auto-generated method stub
        return false;
    }
}

Сойдет?

Сойдёт

 

[hyndorik]

Можно создать 100500 классов со статическими методами и передавать в них твои аргументы, если первый аргумент соответствует create, setminplayers и т.д.
Вот только подумай, нужно ли тебе создавать отдельный класс для метода в 5 строчек?

И да, "азы Java" тут прекрасно работают

Ну дядь вы и говноед, юзайте https://www.spigotmc.org/threads/acf-beta-annotation-command-framework.234266/

 

[AtomicScience]

Ну дядь вы и говноед, юзайте https://www.spigotmc.org/threads/acf-beta-annotation-command-framework.234266/

Неплохая вундервафля, может заюзаю где

 

[alexandrage]

Ну дядь вы и говноед, юзайте https://www.spigotmc.org/threads/acf-beta-annotation-command-framework.234266/

Типо аля рефлкксия == круто? Или че там юзается? Да ты гений.

 

[hyndorik]

Типо аля рефлкксия == круто? Или че там юзается? Да ты гений.

И че плохого? Там вроде не рефлексия юзается а побыстрее чет. Но вообщем то какая разница? Главное удобное, оопшно, java 8, современно

 

[aceJKE]

И че плохого? Там вроде не рефлексия юзается а побыстрее чет. Но вообщем то какая разница? Главное удобное, оопшно, java 8, современно

Ага, "оопшно", 24 паттерном в гоф шли. http://2017.jpoint.ru/talks/java-annotations-are-a-big-mistake/

Конечно там используется рефлексия, в любом случае не стоит беспокоиться о производительности. Удобно и стиль будет схож с обработкой событий.

 

[alexandrage]

Ага, "оопшно", 24 паттерном в гоф шли. http://2017.jpoint.ru/talks/java-annotations-are-a-big-mistake/

Конечно там используется рефлексия, в любом случае не стоит беспокоиться о производительности. Удобно и стиль будет схож с обработкой событий.

О чем и речь. Целый фреймвор с рефлексией, и тот делает совсем не то, что просил тс.

 

[hyndorik]

Ага, "оопшно", 24 паттерном в гоф шли. http://2017.jpoint.ru/talks/java-annotations-are-a-big-mistake/

Конечно там используется рефлексия, в любом случае не стоит беспокоиться о производительности. Удобно и стиль будет схож с обработкой событий.

Ну большинство огромных компаний как-то используют annotation driven spring без кучи xml и как-то все хорошо, и считается, что это круто. Ну то, что может быть не совсем оопшно это да, но опять же с какой точки смотреть, ведь ооп явы то тоже не 100% реальный ооп каким он был изначально

 

[alexandrage]

Ну большинство огромных компаний как-то используют annotation driven spring без кучи xml и как-то все хорошо, и считается, что это круто. Ну то, что может быть не совсем оопшно это да, но опять же с какой точки смотреть, ведь ооп явы то тоже не 100% реальный ооп каким он был изначально

+1 То что по ссылке реально бред.

 

[lyooxa]

if (args[0].equalsIgnoreCase("privet")) {
Privet.getPrivet.usage(CommandSender sender); }

 

[aceJKE]

Ну большинство огромных компаний как-то используют annotation driven spring без кучи xml и как-то все хорошо, и считается, что это круто. Ну то, что может быть не совсем оопшно это да, но опять же с какой точки смотреть, ведь ооп явы то тоже не 100% реальный ооп каким он был изначально

+1 То что по ссылке реально бред.

Я не говорю, что "аннтоации это зло от них нужно избавляться", я говорю о том факте, что аннотации - не ооп подход. В конце концов нужно быть прагматичным и использовать инструменты, которые наиболее подходят для решаемой задачи. Или вы считаете иначе?

Говоря об аннтоация нужно помнить об уместности их применения. Есть задачи, где использовавние аннотаций хорошо ложиться на требования, а есть не очень. Например, в больших проектах, со сложной структурой данных и огромной бизнес-логикой легче будет использовать jooq, а не annotation driven way with hibernate. имхо.

P.S. сейчас в мире программирования ЯП все больше и больше обогащаются "не родными" парадигмами.
Н-р java 8 привносит больше функциональщины, в js добавляются классы, набирают популярность такие языки как scala и kotlin.

О чем и речь. Целый фреймвор с рефлексией, и тот делает совсем не то, что просил тс.

Фреймворк позволяет вроде бы описывать логику подкоманд в отдельном классе, а если это так, то чем не годный ответ?

 

[lyooxa]

if (this.map.contains(args[0])) {
MapExtend me = this.map.get(args[0]);
me.method(); }

 

[hyndorik]

Я не говорю, что "аннтоации это зло от них нужно избавляться", я говорю о том факте, что аннотации - не ооп подход. В конце концов нужно быть прагматичным и использовать инструменты, которые наиболее подходят для решаемой задачи. Или вы считаете иначе?

Говоря об аннтоация нужно помнить об уместности их применения. Есть задачи, где использовавние аннотаций хорошо ложиться на требования, а есть не очень. Например, в больших проектах, со сложной структурой данных и огромной бизнес-логикой легче будет использовать jooq, а не annotation driven way with hibernate. имхо.

P.S. сейчас в мире программирования ЯП все больше и больше обогащаются "не родными" парадигмами.
Н-р java 8 привносит больше функциональщины, в js добавляются классы, набирают популярность такие языки как scala и kotlin.


Фреймворк позволяет вроде бы описывать логику подкоманд в отдельном классе, а если это так, то чем не годный ответ?

Ну на счет hibernate с анотациями то возможно, но спринговские бины и тот же аоп долбить в xml смысла нет

 

[aceJKE]

Ну на счет hibernate с анотациями то возможно, но спринговские бины и тот же аоп долбить в xml смысла нет

А я ничего про спринговые бины и не говорил, это к Егору. А аоп априори не ооп, не понял откуда тут оно вообще.