Помогите Наследование JavaPlugin

[Albert228]

Хотел бы узнать про класс JavaPlugin. Его наследует главный класс плагина. При этом если я в другом классе наследую JavaPlugin, то при запуске плагина появится ошибка, что он уже инициализирован. Как я понял, только главный класс плагина может наследовать этот класс, верно?
В таком случае, скажите пожалуйста, как мне в неглавном классе прописать

getComponentLogger().info(MiniMessage.miniMessage().deserialize(" тестовый текст"));

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

 

[Sturm_PT]

Хотел бы узнать про класс JavaPlugin. Его наследует главный класс плагина. При этом если я в другом классе наследую JavaPlugin, то при запуске плагина появится ошибка, что он уже инициализирован. Как я понял, только главный класс плагина может наследовать этот класс, верно?
В таком случае, скажите пожалуйста, как мне в неглавном классе прописать

getComponentLogger().info(MiniMessage.miniMessage().deserialize(" тестовый текст"));

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

Bukkit.getLogger() ?

 

[Albert228]

Bukkit.getLogger() ?

Я его попробовал. Но тогда у меня подчеркивается MiniMessage.miniMessage()
UPD: сейчас, кажись, понял, что ты имел ввиду. Сейчас попробую так сделать

 

[Albert228]

Я его попробовал. Но тогда у меня подчеркивается MiniMessage.miniMessage()
UPD: сейчас, кажись, понял, что ты имел ввиду. Сейчас попробую так сделать

А, мне показалось, что получится. Попрежнему не могу использовать MiniMessage

 

[Dymeth]

Хотел бы узнать про класс JavaPlugin. Его наследует главный класс плагина. При этом если я в другом классе наследую JavaPlugin, то при запуске плагина появится ошибка, что он уже инициализирован. Как я понял, только главный класс плагина может наследовать этот класс, верно?
В таком случае, скажите пожалуйста, как мне в неглавном классе прописать

getComponentLogger().info(MiniMessage.miniMessage().deserialize(" тестовый текст"));

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

Это не вопрос по баккиту, это вопрос по джаве. Тебе бы не помешало изучить основы языка.

Пойти можно двумя путями:

1) Простой: создать в главном классе статическое поле с инстансом плагина, которое будет назначаться в onEnable()

2) Правильный: передавать инстанс плагина или логгера в конструктор класса, записывать его в поле и затем при необходимости использовать это поле

 

[Albert228]

Это не вопрос по баккиту, это вопрос по джаве. Тебе бы не помешало изучить основы языка.

Пойти можно двумя путями:

1) Простой: создать в главном классе статическое поле с инстансом плагина, которое будет назначаться в onEnable()

2) Правильный: передавать инстанс плагина или логгера в конструктор класса, записывать его в поле и затем при необходимости использовать это поле

Дык подучил немного. По крайне мере посмотрел про ООП. Сейчас усваиваю потихоньку это все. Про наследование как таковое я знаю. Вопрос возник именно из-за этого класса.
Касательно реализации, я сделал так:

public final class CustomSpawningMobs extends JavaPlugin {

    @Override
    public void onEnable() {
    // Plugin startup logic
    messageOnEnable();

    getCommand("spawnmob").setExecutor(new SpawnMob());
    }

    @Override
    public void onDisable() {
    // Plugin shutdown logic
    }

    public void messageOnEnable() {
    getComponentLogger().info(MiniMessage.miniMessage().deserialize("<gradient:#ff4800:#ff8400>" +     "Текст" + "</gradient>"));
    }
}

Как я понял, это как раз первый способ реализации. А как тогда второй делать? Что-то я не понял немного, какой конструктор?

 

[alexandrage]

Дык подучил немного. По крайне мере посмотрел про ООП. Сейчас усваиваю потихоньку это все. Про наследование как таковое я знаю. Вопрос возник именно из-за этого класса.
Касательно реализации, я сделал так:

public final class CustomSpawningMobs extends JavaPlugin {

    @Override
    public void onEnable() {
    // Plugin startup logic
    messageOnEnable();

    getCommand("spawnmob").setExecutor(new SpawnMob());
    }

    @Override
    public void onDisable() {
    // Plugin shutdown logic
    }

    public void messageOnEnable() {
    getComponentLogger().info(MiniMessage.miniMessage().deserialize("<gradient:#ff4800:#ff8400>" +     "Текст" + "</gradient>"));
    }
}

Как я понял, это как раз первый способ реализации. А как тогда второй делать? Что-то я не понял немного, какой конструктор?

 

[Albert228]

Это не вопрос по баккиту, это вопрос по джаве. Тебе бы не помешало изучить основы языка.

Пойти можно двумя путями:

1) Простой: создать в главном классе статическое поле с инстансом плагина, которое будет назначаться в onEnable()

2) Правильный: передавать инстанс плагина или логгера в конструктор класса, записывать его в поле и затем при необходимости использовать это поле

Если честно, я уже полдня пытаюсь осмыслить это сообщение. Я посмотрел несколько раз видос про конструкторы, который мне кинули. В принципе, я про них знал. Но в данном случае я как-то не понимаю, что нужно делать. Моя задача заключается в том, чтобы отделить как-то вывод сообщения в консоль. Сначала я хотел в отдельный класс это сунуть. У меня это не получилось и я в главном классе написал метод messageOnEnable(), в котором и вывожу текст. А уже в методе onEnable() я обращаюсь к messageOnEnable().

Спойлер: мой код

package me.xlalbertlx.customspawningmobs;

import me.xlalbertlx.customspawningmobs.commands.SpawnMob;
import net.kyori.adventure.text.minimessage.MiniMessage;
import org.bukkit.plugin.java.JavaPlugin;

public final class CustomSpawningMobs extends JavaPlugin {

@Override
public void onEnable() {
// Plugin startup logic
messageOnEnable();

getCommand("spawnmob").setExecutor(new SpawnMob());
}

@Override
public void onDisable() {
// Plugin shutdown logic
}

public void messageOnEnable() {
getComponentLogger().info(MiniMessage.miniMessage().deserialize("<gradient:#ff4800:#ff8400>" + "text" + "</gradient>"));
}
}

Хотел бы узнать, на сколько правильна такая запись. Стоит ли сообщения делать в отдельном классе? Если так нужно, то скажите пожалуйста, как реализовать это:

передавать инстанс плагина или логгера в конструктор класса, записывать его в поле и затем при необходимости использовать это поле

 

[Dymeth]

Пока не смотрел код, общий принцип второго подхода такой: есть главный класс плагина, допустим MyPlugin. Он наследует JavaPlugin.
Есть второстепенный класс, например CustomSpawningMobs. Он НЕ наследует JavaPlugin. Там создаётся конструктор, который принимает главный класс плагина MyPlugin. Внутри конструктора свой главный класс записываешь в поле. А в главном классе MyPlugin создаёшь новый объект типа CustomSpawningMobs и передаешь в конструктор текущий объект (самого себя) при помощи this

 

[alexandrage]

Если честно, я уже полдня пытаюсь осмыслить это сообщение. Я посмотрел несколько раз видос про конструкторы, который мне кинули. В принципе, я про них знал. Но в данном случае я как-то не понимаю, что нужно делать. Моя задача заключается в том, чтобы отделить как-то вывод сообщения в консоль. Сначала я хотел в отдельный класс это сунуть. У меня это не получилось и я в главном классе написал метод messageOnEnable(), в котором и вывожу текст. А уже в методе onEnable() я обращаюсь к messageOnEnable().

Спойлер: мой код

package me.xlalbertlx.customspawningmobs;

import me.xlalbertlx.customspawningmobs.commands.SpawnMob;
import net.kyori.adventure.text.minimessage.MiniMessage;
import org.bukkit.plugin.java.JavaPlugin;

public final class CustomSpawningMobs extends JavaPlugin {

@Override
public void onEnable() {
// Plugin startup logic
messageOnEnable();

getCommand("spawnmob").setExecutor(new SpawnMob());
}

@Override
public void onDisable() {
// Plugin shutdown logic
}

public void messageOnEnable() {
getComponentLogger().info(MiniMessage.miniMessage().deserialize("<gradient:#ff4800:#ff8400>" + "text" + "</gradient>"));
}
}

Хотел бы узнать, на сколько правильна такая запись. Стоит ли сообщения делать в отдельном классе? Если так нужно, то скажите пожалуйста, как реализовать это:

Тебе нужно this передать в конструктор, это и будет ссылка на объект класса.

 

[Albert228]

Пока не смотрел код, общий принцип второго подхода такой: есть главный класс плагина, допустим MyPlugin. Он наследует JavaPlugin.
Есть второстепенный класс, например CustomSpawningMobs. Он НЕ наследует JavaPlugin. Там создаётся конструктор, который принимает главный класс плагина MyPlugin. Внутри конструктора свой главный класс записываешь в поле. А в главном классе MyPlugin создаёшь новый объект типа CustomSpawningMobs и передаешь в конструктор текущий объект (самого себя) при помощи this

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

 

[alexandrage]

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

Да в этом совсем нет смысла, ради одного сообщения целый класс с методом.

 

[Dymeth]

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

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

Когда я писал про правильность - я имел в виду разницу со статическим геттером инстанса плагина. Проблема статики в том, что она нарушает принцип зависимостей между классами (то самое ООП). Да, ты можешь из любого места получить плагин, но с увеличением твоего плагина это начнёт приносить всё больше и больше сложностей - расширяемость, гибкость, даже читабельность - всё это будет страдать. Вот тут расписывали подробней:

https://rubukkit.org/threads/182218
https://rubukkit.org/threads/183853

 

[Albert228]

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

Когда я писал про правильность - я имел в виду разницу со статическим геттером инстанса плагина. Проблема статики в том, что она нарушает принцип зависимостей между классами (то самое ООП). Да, ты можешь из любого места получить плагин, но с увеличением твоего плагина это начнёт приносить всё больше и больше сложностей - расширяемость, гибкость, даже читабельность - всё это будет страдать. Вот тут расписывали подробней:

https://rubukkit.org/threads/182218
https://rubukkit.org/threads/183853

Да в этом совсем нет смысла, ради одного сообщения целый класс с методом.

Понял, спасибо вам большое)

 

[IlyaHaker]

2) Правильный: передавать инстанс плагина или логгера в конструктор класса, записывать его в поле и затем при необходимости использовать это поле

но основной класс плагина же - фактически синглтон, и в чем разница тогда между классической реализацией этого шаблона проектирования и случаем с главным классом? в синглтоне ведь через статику передается объект

 

[Dymeth]

но основной класс плагина же - фактически синглтон, и в чем разница тогда между классической реализацией этого шаблона проектирования и случаем с главным классом? в синглтоне ведь через статику передается объект

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

 

[alexandrage]

Все делается для удобства, что бы потом не запутаться что и для чего.