[1.14-1.16] Spring Bootstrap

7,099
324
1,509
И чем это лучше EventBusSubscriber?
 
170
2
53
Я бы не стал сравнивать два этих способа, каждый из них хорош. Я предпочитаю DI, а EventBusSubscriber, по моему работает только со статиками (но это не точно). Да и зачем сканировать EventBusSubscriber, когда уже идет сканирование Component? Раз уж я использую Component, то интерфейс будет более разумным решением.
 
7,099
324
1,509
А какой смысл хандлеру быть не статичным, если он синглтон по сути?
 
170
2
53
Depends Injection, он будет зарегистрирован только тогда, когда в нем будет спрос, что полезно для API. Но при этом, его реализаця всегда будет наготове. Проще слушать это в самом сервисе, тогда сразу интуитивно понятно, для чего он. Есть сервис, который отвечает за временный парализ существа, если игрок нажимает шифт - он выходит из этого состояния. Сервис контролирует, чтобы этого не произошло. Если контролировать это статично, то часто для событий создают класс, который их прослушивает и тогда, чтобы понять всю логику сервиса, нужно найти класс, который прослушивает нужное событие и смотреть там, что отнимает время разработки в крупном проекте. Плюс ко всему этому, необходимо будет в статический слушатель событий передавать instance самого сервиса, что добавит как минимум еще один статик, и будет срабатывать каждый раз при вызове ивента, а что если сервис такой не один? Постоянно передавать инстанс? Я думаю лучше слушать прямо в сервисе, тем самым избежать этого. В этом в разы больше плюсов, чем минусов
 
7,099
324
1,509
Все равно не понимаю, как это экономит время разработки.
Если контролировать это статично, то часто для событий создают класс, который их прослушивает и тогда, чтобы понять всю логику сервиса, нужно найти класс, который прослушивает нужное событие и смотреть там, что отнимает время разработки в крупном проэкте
А его, типо, найти сложно? А если в этом классе хандлеры не статичные, то он быстрее найдется? Почему? В обоих случаях будет использоваться фича ide "find usages", для нее ведь нет разницы, статичный метод или нет
 
170
2
53
В обоих случаях будет использоваться фича ide "find usages"
Давать попробую объяснить на примере, как я понял, ты уже согласен с тем, что передавать постоянно инстанс не так разумно, давай расскажу теперь про удобство в поиске.
У нас есть Механика "А", которая слушает Cобытие "А". У нас есть Механика "Б", которая слушает Cобытие "А". Какое решение тут можно принять? Создать класс, Handler, который будет слушать событие А для обоих механик, в который мы будет статично передавать Instance Механики "A" и "Б", допустим этот код писал не ты, тебе нужно разобраться в нем, чтобы понять, что именно для механики А, а что именно для Механики Б, это уже тратит твое время, правильно? Думаю да. Какое решение мы можем принять еще? Статично зарегистрировать ивент в классе механики, но тогда мы все так же будем статично передавать туда Instance этой механики. Ничего сложного, но, а что если у нас две реализации Механики А (Механика А => Абстракт Механика А => Стандартная Механика А и Расширенная Механика А)? Мы будем повторять это действие до усёра? Тоже не совсем удобно. Ну и мы можем принять решение, которые я уже описал выше, которое превосходит предыдущие из-за отсутствия статики, удобства в разработке и в работе с ним.
 
7,099
324
1,509
Прочитал.
При каких случаях при работе с событиями могут появиться зависимости хандлера от чего-либо?
Статичный вариант без инстансов:
Java:
@EventBusSubscriber
public class MechA{
    @SubscribeEvent
    public static void onA(EventA event){
        //механика А
    }
}
@EventBusSubscriber
public class MechB{
    @SubscribeEvent
    public static void onA(EventA event){
        //механика B
    }
}
От чего может зависеть MechA?
В примере с паралайзом хандлеры тоже ни от чего не зависят.
Можно придумать пример, где хандлеру нужна какая-то вещь, например, предмет или блок. Итем регается в одном месте, а юзается во множестве других, поэтому он может рассматриваться как зависимость.
Тогда почему бы не сделать так:
Java:
@EventBusSubscriber
public class MechA{
    @ObjectHolder("registry:name") // инъекция в статическое поле
    public static MyItem item;

    @SubscribeEvent
    public static void onA(EventA event){
        //механика А
    }
}
Чем это хуже и лучше варианта с конструктором?
Java:
@EventBusSubscriber
public class MechA{
    private MyItem item;
    public MechA(@ObjectHolder("registry:name") MyItem item){
        this.item=item;
    }

    @SubscribeEvent
    public void onA(EventA event){
        //механика А
    }
}
Кажется, проблемы могут возникнуть при попытке параллельных применений хандлера(в статье говорится о параллельных тестах)
 
170
2
53
Мы скорее говорим о разном. Ты говоришь о проблемах, а я говорю об удобстве, но по факту у всех свое представление комфорта и удобства. Мне проще сканировать компонент только
 

GoogleTan

Картошка :3
1,354
43
310
Я думаю, лучше будет оформить, как статью про миксины(там человек явно хочет показать в чем удобство и когда это нужно юзать). Я так и не нашла того, что тут есть... Ни в теме(4 раза прочитала и так и не поняла), ни в гите не сказано, что я могу этим делать, и зачем это может быть мне полезно? Ссылка на пример битая.
------------------------------------------------------------------------------------------------------------
Приучить сообщество к правильному ООП, чтобы сервисы не висели статичными
Берем котлин и все решается само собой. Тут нету статик методов и функций.
 
7,099
324
1,509
А можешь опубликовать два варианта одного и того же мода, сделанный на голом форж и с использованием спринга?
 
7,099
324
1,509
MinecraftForgeSpringContextInitializer
Я уже чувствую, как запахло энтерпразом))

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

Icosider

Kotliner
Администратор
3,600
99
663
Ну ёп, спалили xd Чтобы отправить мод в готовые, он должен быть закончен. Логично же)) Если ты уверен в том, что он запускается, исправно работает и никто не испытывает дискомфорта при работе с ним, то я могу перенести его в готовые моды. Но судя по состоянию моду, он скорей труп, чем рабочий)
 
Сверху