А его, типо, найти сложно? А если в этом классе хандлеры не статичные, то он быстрее найдется? Почему? В обоих случаях будет использоваться фича ide "find usages", для нее ведь нет разницы, статичный метод или нетЕсли контролировать это статично, то часто для событий создают класс, который их прослушивает и тогда, чтобы понять всю логику сервиса, нужно найти класс, который прослушивает нужное событие и смотреть там, что отнимает время разработки в крупном проэкте
Давать попробую объяснить на примере, как я понял, ты уже согласен с тем, что передавать постоянно инстанс не так разумно, давай расскажу теперь про удобство в поиске.В обоих случаях будет использоваться фича ide "find usages"
@EventBusSubscriber
public class MechA{
@SubscribeEvent
public static void onA(EventA event){
//механика А
}
}
@EventBusSubscriber
public class MechB{
@SubscribeEvent
public static void onA(EventA event){
//механика B
}
}
@EventBusSubscriber
public class MechA{
@ObjectHolder("registry:name") // инъекция в статическое поле
public static MyItem item;
@SubscribeEvent
public static void onA(EventA event){
//механика А
}
}
@EventBusSubscriber
public class MechA{
private MyItem item;
public MechA(@ObjectHolder("registry:name") MyItem item){
this.item=item;
}
@SubscribeEvent
public void onA(EventA event){
//механика А
}
}
Берем котлин и все решается само собой. Тут нету статик методов и функций.Приучить сообщество к правильному ООП, чтобы сервисы не висели статичными
У меня нету такого желания, в первую очередь делал для себя. Про возможности мода можно узнать из readme на git. Про возможности Spring можно узнать в интернете.хочет показать в чем удобство
Задача мода подружить один из самых популярный java framework с forge, а про это самый framework "Spring" в интернете множество тем.зачем это может быть мне полезно
Я уже чувствую, как запахло энтерпразом))MinecraftForgeSpringContextInitializer
С чем связаны такие выводы? Всё нормально работаетон скорей труп, чем рабочий