автовырезалка v03.4

[hohserg]

Тогда зачем вырезалка?

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

 

[CumingSoon]

>> архитектура
>> нет паттернов
Серьезно что ли? Нормальная архитектура уже подразумевает, что клиент и сервер раздельны. Поэтому как бы и вырезать там нечего.

 

[JustAGod]

Ты либо дэбил
Либо толстый троль
В любом случае кончай

 

[hohserg]

нет паттернов

Я имел ввиду те паттерны, которые предназначены для разделения клиента и сервера

 

[MJaroslav]

Дурачок вкатывается в тред.
Я разделяю (только заказы) на три пакета common, server, client. Ну и вырезаю в jar клиента server и наоборот (пока ручками). Однако у меня это не будет работать в одиночно игре, ибо все блоки, предметы и прочие делимые вещи у меня в двух экземплярах: один для сервера, другой для клиента (не лучший подход, но меня устраивает). Вот если вырезалка позволяет запускать код в IDE, чтобы логика работала и в одиночной игре, а при сборке разделять так, чтобы она уже отсутствовала в клиентской версии мода, то это гуд и маст хев просто.

 

[JustAGod]

ну ты почитай, что она делает.
Спойлер
то что ты описал

 

[CumingSoon]

Ты либо дэбил
Либо толстый троль
В любом случае кончай

Я тебя не оскорблял, да и не знаю, где ты тролленг увидел, шизик

Я имел ввиду те паттерны, которые предназначены для разделения клиента и сервера

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

 

[will0376]

потому что хорошая архитектура

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

 

[JustAGod]

Серьезно что ли? Нормальная архитектура уже подразумевает, что клиент и сервер раздельны. Поэтому как бы и вырезать там нечего.

Нет. Хорошая архитектура подразумевает хорошую масштабируемость. Майнкрафт не делит на клиент/сервер.Выходит архитектура мода тоже не должна такое предполагать.

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

Почему ты затираешь бред с такой уверенностью в себе?
Давай пройдемся по некоторым паттернам:
1) Декоратор
2) Делегат
3) Адаптер
4) Фабрика
5) Фабричный метод

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

потому что хорошая архитектура не допустит смеси клиента и сервера. Это все равно, что инцест. Нельзя скрещивать их в общий код

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

>> архитектура
>> нет паттернов
Серьезно что ли? Нормальная архитектура уже подразумевает, что клиент и сервер раздельны. Поэтому как бы и вырезать там нечего.

ты опять путаешь разделение и паттерны
ты опять путаешь применение паттернов и архитектуру

 

[CumingSoon]

Но Жабакодеры на форуме в большинстве в своём - новички, которые только начинают писать.

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

Хорошая архитектура подразумевает хорошую масштабируемость.

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

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

Это ещё что и к чему? Я такого вообще не говорил. Я грю о том, что клиент не должен никак зависеть от сервера впрочем как и наоборот. Тупо по определению.

в нормальных приложухах имеется смысол, но не в майне

А что, майн это особое приложение? Кстати, тут есть фичи для разделения. Это прокси, несколько реализаций игроков, два или три мира, отдельные инстансы под клиент и сервер (MinecraftServer/Minecraft). Всё ещё не хватает?
Да даже сам майн кое-как делит свои пакеты на общие и серверные.

ты опять путаешь разделение и паттерны

Паттерны помогают делить код удобно, не придумывая костылей, которые за тебя уже придумали.

ты опять путаешь применение паттернов и архитектуру

Хорошая архитектура использует паттерны. Потому что практика наработана годами, за тебя уже определили где и что писать нужно, чтобы легко изменялось, быстро работало и т.д.

 

[tox1cozZ]

А можно чтобы когда запускаешь сервер оно применяло эти аннотации и не нужно было еще сверху вешать SideOnly(Side.CLIENT), а то сервер падает? Такое реально вообще? Или придется копировать трансформер SideOnly для своих аннотаций?

 

[JustAGod]

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

Хз с каких пор хорошая масштабируемость стала подразумевать модульность. Модульность - это прием организации, но точно не показатель хорошей масштабируемости. Опять путаешь.

Это ещё что и к чему? Я такого вообще не говорил. Я грю о том, что клиент не должен никак зависеть от сервера впрочем как и наоборот. Тупо по определению.

Выражайте мысли яснее. Я понял так.

А что, майн это особое приложение? Кстати, тут есть фичи для разделения. Это прокси, несколько реализаций игроков, два или три мира, отдельные инстансы под клиент и сервер (MinecraftServer/Minecraft). Всё ещё не хватает?
Да даже сам майн кое-как делит свои пакеты на общие и серверные.

Паттерны помогают делить код удобно, не придумывая костылей, которые за тебя уже придумали.

Рассказываю секрет. При текущих реалиях кода майнкруфтов "правильный дизайн кода" тупа не практичен.

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

Ты, конечно, можешь привести в пример наследование, но тогда нужно делать архитектуру уровня: CommonModule, ClientModule, ServerModule. Конечно, это возможно, но это не освобождает тебя от тупейшего бойлерплэйта. Плюс ко всему, форж порой ведет себя совсем по-дурацки когда дело доходит до многомодульности. Вам теоретикам не понять.

И по сему, я, умея во все твои прокси/паттерны(лол ты дэбил чоли тут "/" писать. прокси это паттерн мех), все же предпочитаю писать код быстро, а не выпендриваться своими скилами в ООП.

Хорошая архитектура использует паттерны. Потому что практика наработана годами, за тебя уже определили где и что писать нужно, чтобы легко изменялось, быстро работало и т.д.

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

 

[JustAGod]

А можно чтобы когда запускаешь сервер оно применяло эти аннотации и не нужно было еще сверху вешать SideOnly(Side.CLIENT), а то сервер падает? Такое реально вообще? Или придется копировать трансформер SideOnly для своих аннотаций?

Да, можешь в build.gradle указать путь не до GradleSideOnly, а юзать форжевскую. По идее должно сработать.

 

[CumingSoon]

Хз с каких пор хорошая архитектура стала подразумевать модульность. Модульность - это прием организации, но точно не показатель хорошей архитектуры. Опять путаешь.

Опять не читаешь. Я не утверждал, что модульность = хорошая архитектура. Она бывает излишня, посему это не обязательный атрибут хорошего кода. Ну, в общем, перечитай ещё раз сообщение. Особенно вот этот момент: "Хорошая архитектура подразумевает читаемый код, котоырй вряд ли будет содержать баги". Не вижу слова "модульность"

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

Может. Однако всю нормальную архитекутру задекларировали уже при помощи паттернов. Не нужно писать велосипед, всё уже готово. В прочем, и это я уже писал

 

[tox1cozZ]

Хм, работает. До этого пробовал чот не пахало) Спасибо

 

[JustAGod]

Опять не читаешь. Я не утверждал, что модульность = хорошая архитектура. Она бывает излишня, посему это не обязательный атрибут хорошего кода. Ну, в общем, перечитай ещё раз сообщение. Особенно вот этот момент: "Хорошая архитектура подразумевает читаемый код, котоырй вряд ли будет содержать баги". Не вижу слова "модульность"

Ок

Хз с каких пор хорошая масштабируемость стала подразумевать модульность. Модульность - это прием организации, но точно не показатель хорошей масштабируемости. Опять путаешь.

 

[CumingSoon]

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

 

[CumingSoon]

И вообще, при чём тут это, если изначально речь шла об адекватном делении на сервер/клиент с последующим использованием различных паттернов типа прокси для удобного деления?
Кстати, можно и без прокси. Просто писать отдельно кеод для сервера, а отдельно для клиента. Верно же будет, что мод, лежащий на клиенте, это всегда клиентская часть. А его вторая половинка - серверная. Тут даже прокси не нужны. Только правильно делить
Прокси юзаются, что склеить общую часть с клиент/сервером. Причём так склеить, что эта самая общая часть не будет зависеть ни от клиента, ни от сервера. (как же всё это удобно в uml рисуется)

 

[tox1cozZ]

Просто писать отдельно кеод для сервера, а отдельно для клиента.

У майна очень много мест с общим кодом. Взять те же блоки, предметы, сущности. Постоянно туда-сюда копировать дико неудобно, что-то да забудешь. А так аннотацию повесил и забыл.

 

[JustAGod]

Это самый эффективный и удобный способ - расширять программу посредством модулей.

Самый эффективный способ расширить программу по средствам модулей - использование модулей. Ну тут я согласен лол.

Ну а как ты иначе оформишь масштабируемость, кроме как модульности?

С помощью принципов SOLID разработки

А если можно делать модули, то разве это не масштабируемость?

Модули нужны не для масштабируемости, а для логического деления зависимостей.

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

Потому что это, очевидно, неудобно.

Прокси юзаются, что склеить общую часть с клиент/сервером. Причём так склеить, что эта самая общая часть не будет зависеть ни от клиента, ни от сервера.

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