Вопрос по создании сложного API для ядра и маленького количества модулей

iLoco

Пишу плагины за печеньки 🍪🍪🍪
Сообщения
2,265
Реакции
1,323
Есть ли вообще какой-то смысл затрачивать свои силы на создание сложное API со всякими CallBack'ами, защитами структуры и прочего для ядра, максимум у него будет 10 модулей, не более, и то, эти модули будут написаны тем-же автором, что и ядро писал?
 
Решение
В чистом ядре, без API, +-1000 строчек. Не соглашусь что в ядре не прийдётся после релиза копаться, ведь мы же не стоим на месте, ка всегда приходят новые идеи, и без нужного функционала (API) этого не сделаешь. Оффтоп
Ну если реализуешь хорошо API, вполне реально на длительное время забыть про ядро и смотреть только в модули и API.

Сложное, это продумать систему регистрации модулей, ведь нужно как-то информацию выводить в менюшки и тд.
Абсолютно не проблема, особенно учитывая наличие примеров (шоп, вип, тот же jwp от TiBari).

Так-же затрону CallBack, которые тоже не просты в своём строении, ихную информацию тоже структурировать приходится
От модулей? Это не всегда большая...

Madness aka null138

Участник
Сообщения
721
Реакции
779
Если количество модулей известно до точности и добавление в будущем новых точно не будет, то смысла делать как по мне нет.
Но я обычно для себя делаю пару нативов и форвардов на всякий случай и то самые главные вроде хендлов бд и т.д.
 

Rabb1t

Амбассадор
Сообщения
2,968
Реакции
1,429
  • Команда форума
  • #3
Имхо, есть.

Как минимум модульность всегда удобнее как в работе с кодом, так и в использовании готового решения.
Но опять же вопрос в том, что ты подразумеваешь в "сложном" API.
В чем главный плюс хорошо продуманного и реализованного API, на мой взгляд, так это зачастую упрощает работу с модулями. То есть тебе уже не столько нужно копаться в ядре (где кода тьма и без этого), а просто редактировать модуль или API. Плюс ко всему заранее продуманное API даст хороший потенциал забыть про его редактирование (кроме багов и крашей).

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

iLoco

Пишу плагины за печеньки 🍪🍪🍪
Сообщения
2,265
Реакции
1,323
В чем главный плюс хорошо продуманного и реализованного API, на мой взгляд, так это зачастую упрощает работу с модулями. То есть тебе уже не столько нужно копаться в ядре (где кода тьма и без этого), а просто редактировать модуль или API. Плюс ко всему заранее продуманное API даст хороший потенциал забыть про его редактирование (кроме багов и крашей).
В чистом ядре, без API, +-1000 строчек. Не соглашусь что в ядре не прийдётся после релиза копаться, ведь мы же не стоим на месте, ка всегда приходят новые идеи, и без нужного функционала (API) этого не сделаешь. Оффтоп

Но опять же вопрос в том, что ты подразумеваешь в "сложном" API.
Сложное, это продумать систему регистрации модулей, ведь нужно как-то информацию выводить в менюшки и тд. Так-же затрону CallBack, которые тоже не просты в своём строении, ихную информацию тоже структурировать приходится, для меня это только ArrayList или KV, всякие DataPack ну такое... Оффтоп
 

Rabb1t

Амбассадор
Сообщения
2,968
Реакции
1,429
  • Команда форума
  • #5
В чистом ядре, без API, +-1000 строчек. Не соглашусь что в ядре не прийдётся после релиза копаться, ведь мы же не стоим на месте, ка всегда приходят новые идеи, и без нужного функционала (API) этого не сделаешь. Оффтоп
Ну если реализуешь хорошо API, вполне реально на длительное время забыть про ядро и смотреть только в модули и API.

Сложное, это продумать систему регистрации модулей, ведь нужно как-то информацию выводить в менюшки и тд.
Абсолютно не проблема, особенно учитывая наличие примеров (шоп, вип, тот же jwp от TiBari).

Так-же затрону CallBack, которые тоже не просты в своём строении, ихную информацию тоже структурировать приходится
От модулей? Это не всегда большая проблема, можно все заносить, например, в StringMap'ы, а их в тот же ArrayList, есть у меня один пример такой, посоветовал @Коробка из под бананов как-то, достаточно удобный вариант, правда изначально я не правильно начал работу с этим и вместо вспомогательных функций решил заюзать несколько однотипных циклов в разных местах, тот еще прикол вышел.

Не до конца их учил, да и позицию в длинном паке фиг поставить
Опыт лишним не будет никогда.
 
Решение

iLoco

Пишу плагины за печеньки 🍪🍪🍪
Сообщения
2,265
Реакции
1,323
Абсолютно не проблема, особенно учитывая наличие примеров (шоп, вип, тот же jwp от TiBari).
Как-то я посмотрел туда, и у меня отбило желание что-то делать в тот день, LR тоже смотрел.

От модулей? Это не всегда большая проблема, можно все заносить, например, в StringMap'ы, а их в тот же ArrayList, есть у меня один пример такой, посоветовал @Коробка из под бананов как-то, достаточно удобный вариант, правда изначально я не правильно начал работу с этим и вместо вспомогательных функций решил заюзать несколько однотипных циклов в разных местах, тот еще прикол вышел.
Поделитесь?
 

Rabb1t

Амбассадор
Сообщения
2,968
Реакции
1,429
  • Команда форума
  • #7
Имхо, но там реализация мне не понравилась вообще, да и до сих пор не нравится, особенно когда просят сделать какую-то интеграцию с ним и часто приходится костылить, т.к. в API всего нет (ps, писал и Вендеру, и Ромео, пока ничего не добавлено на момент написания поста).
ак-то я посмотрел туда, и у меня отбило желание что-то делать в тот день
Это лишь на первый взгляд сложно и запутанно. На самом деле если вникнуть, оказывается, что это достаточно хорошо продуманное API, и пока из всего что я встречал - лучше, пожалуй, не было.

Не думаю, что хорошо будет это в паблик закидывать, приват. Если нужно, напиши в телегу или дискорд (все в профиле).
 

Kruzya

Участник
Сообщения
12,970
Реакции
10,927
  • Команда форума
  • #8
Я какое-то время грезил о возможности перехватывать вызовы функций/нативов внутри левых плагинов. Вот это может вызвать конкретное расширение функционала любого плагина, если функции помечены пабликом, и апи для них никакого явного нет.
Но пока даже не разбирался, как хукаться в джите, чтобы осуществить мечту. Может быть, когда-нибудь.
 
Сверху Снизу