- 7,099
- 324
- 1,510
Может быть, кто-то не хочет использовать эти паттерны только ради того чтобы скрывать код серверной части. Для него это не основная задача, поэтому нецелесообразно извращать архитектуру проекта ради нее.Тогда зачем вырезалка?
Может быть, кто-то не хочет использовать эти паттерны только ради того чтобы скрывать код серверной части. Для него это не основная задача, поэтому нецелесообразно извращать архитектуру проекта ради нее.Тогда зачем вырезалка?
Я имел ввиду те паттерны, которые предназначены для разделения клиента и серверанет паттернов
Я тебя не оскорблял, да и не знаю, где ты тролленг увидел, шизикТы либо дэбил
Либо толстый троль
В любом случае кончай
Ну ты сам это и сказал. Они предназначены для этого. Это типа дорожка на пути к правильной архитектуре мода, да и вообще любого клиент/сервера.Я имел ввиду те паттерны, которые предназначены для разделения клиента и сервера
Архитектура может и хорошая. Но Жабакодеры на форуме в большинстве в своём - новички, которые только начинают писать.потому что хорошая архитектура
Нет. Хорошая архитектура подразумевает хорошую масштабируемость. Майнкрафт не делит на клиент/сервер.Выходит архитектура мода тоже не должна такое предполагать.Серьезно что ли? Нормальная архитектура уже подразумевает, что клиент и сервер раздельны. Поэтому как бы и вырезать там нечего.
Почему ты затираешь бред с такой уверенностью в себе?Ну ты сам это и сказал. Они предназначены для этого. Это типа дорожка на пути к правильной архитектуре мода, да и вообще любого клиент/сервера.
можно. особенно в реалиях майна, где уже такпотому что хорошая архитектура не допустит смеси клиента и сервера. Это все равно, что инцест. Нельзя скрещивать их в общий код
ты опять путаешь разделение и паттерны>> архитектура
>> нет паттернов
Серьезно что ли? Нормальная архитектура уже подразумевает, что клиент и сервер раздельны. Поэтому как бы и вырезать там нечего.
Поэтому стоит учиться юзать вырезалку, а не изучать паттерны и проектирование кода? Ок, ты выигралНо Жабакодеры на форуме в большинстве в своём - новички, которые только начинают писать.
Нет, хорошую масштабируемость подразумевает модульность. Хорошая архитектура подразумевает читаемый код, котоырй вряд ли будет содержать баги.Хорошая архитектура подразумевает хорошую масштабируемость.
Это ещё что и к чему? Я такого вообще не говорил. Я грю о том, что клиент не должен никак зависеть от сервера впрочем как и наоборот. Тупо по определению.Ты серьезно утверждаешь, что они применяются для разделения клиента и сервера?
А что, майн это особое приложение? Кстати, тут есть фичи для разделения. Это прокси, несколько реализаций игроков, два или три мира, отдельные инстансы под клиент и сервер (MinecraftServer/Minecraft). Всё ещё не хватает?в нормальных приложухах имеется смысол, но не в майне
Паттерны помогают делить код удобно, не придумывая костылей, которые за тебя уже придумали.ты опять путаешь разделение и паттерны
Хорошая архитектура использует паттерны. Потому что практика наработана годами, за тебя уже определили где и что писать нужно, чтобы легко изменялось, быстро работало и т.д.ты опять путаешь применение паттернов и архитектуру
Хз с каких пор хорошая масштабируемость стала подразумевать модульность. Модульность - это прием организации, но точно не показатель хорошей масштабируемости. Опять путаешь.Нет, хорошую масштабируемость подразумевает модульность. Хорошая архитектура подразумевает читаемый код, котоырй вряд ли будет содержать баги.
Выражайте мысли яснее. Я понял так.Это ещё что и к чему? Я такого вообще не говорил. Я грю о том, что клиент не должен никак зависеть от сервера впрочем как и наоборот. Тупо по определению.
А что, майн это особое приложение? Кстати, тут есть фичи для разделения. Это прокси, несколько реализаций игроков, два или три мира, отдельные инстансы под клиент и сервер (MinecraftServer/Minecraft). Всё ещё не хватает?
Да даже сам майн кое-как делит свои пакеты на общие и серверные.
Паттерны помогают делить код удобно, не придумывая костылей, которые за тебя уже придумали.
Рассказываю секрет. При текущих реалиях кода майнкруфтов "правильный дизайн кода" тупа не практичен.
Допустим, у тебя есть блок, и у него есть какое то поведение в тике, которое отличается на клиенте и на сервере. Например, на клиенте оно фигачит партиклы, а на сервере раздает всем кто рядышком какие то хреновины, анализируя потребности нейросеткой. Я не хочу, чтобы кто-то стырил мою нейросетку, а потому при каждом клиентском билде вырезаю метод с ней плагином к градлу при помощи одной аннотации, имея при этом одну кодовую базу. В твоем же случае придется фигачить два проекта. Это нормально ровно до тех пор, пока у тебя нет общего кода для обеих сторон, а он, как правило, всегда есть. В результате постоянные ляпсусы уровня: упс, забыл скопировать.
Ты, конечно, можешь привести в пример наследование, но тогда нужно делать архитектуру уровня: CommonModule, ClientModule, ServerModule. Конечно, это возможно, но это не освобождает тебя от тупейшего бойлерплэйта. Плюс ко всему, форж порой ведет себя совсем по-дурацки когда дело доходит до многомодульности. Вам теоретикам не понять.
И по сему, я, умея во все твои прокси/паттерны(лол ты дэбил чоли тут "/" писать. прокси это паттерн мех), все же предпочитаю писать код быстро, а не выпендриваться своими скилами в ООП.
архитектура может их и не использовать, но это уже другая темаХорошая архитектура использует паттерны. Потому что практика наработана годами, за тебя уже определили где и что писать нужно, чтобы легко изменялось, быстро работало и т.д.
Да, можешь в build.gradle указать путь не до GradleSideOnly, а юзать форжевскую. По идее должно сработать.А можно чтобы когда запускаешь сервер оно применяло эти аннотации и не нужно было еще сверху вешать SideOnly(Side.CLIENT), а то сервер падает? Такое реально вообще? Или придется копировать трансформер SideOnly для своих аннотаций?
Опять не читаешь. Я не утверждал, что модульность = хорошая архитектура. Она бывает излишня, посему это не обязательный атрибут хорошего кода. Ну, в общем, перечитай ещё раз сообщение. Особенно вот этот момент: "Хорошая архитектура подразумевает читаемый код, котоырй вряд ли будет содержать баги". Не вижу слова "модульность"Хз с каких пор хорошая архитектура стала подразумевать модульность. Модульность - это прием организации, но точно не показатель хорошей архитектуры. Опять путаешь.
Может. Однако всю нормальную архитекутру задекларировали уже при помощи паттернов. Не нужно писать велосипед, всё уже готово. В прочем, и это я уже писалархитектура может их и не использовать, но это уже другая тема
ОкОпять не читаешь. Я не утверждал, что модульность = хорошая архитектура. Она бывает излишня, посему это не обязательный атрибут хорошего кода. Ну, в общем, перечитай ещё раз сообщение. Особенно вот этот момент: "Хорошая архитектура подразумевает читаемый код, котоырй вряд ли будет содержать баги". Не вижу слова "модульность"
Хз с каких пор хорошая масштабируемость стала подразумевать модульность. Модульность - это прием организации, но точно не показатель хорошей масштабируемости. Опять путаешь.
У майна очень много мест с общим кодом. Взять те же блоки, предметы, сущности. Постоянно туда-сюда копировать дико неудобно, что-то да забудешь. А так аннотацию повесил и забыл.Просто писать отдельно кеод для сервера, а отдельно для клиента.
Самый эффективный способ расширить программу по средствам модулей - использование модулей. Ну тут я согласен лол.Это самый эффективный и удобный способ - расширять программу посредством модулей.
С помощью принципов SOLID разработкиНу а как ты иначе оформишь масштабируемость, кроме как модульности?
Модули нужны не для масштабируемости, а для логического деления зависимостей.А если можно делать модули, то разве это не масштабируемость?
Потому что это, очевидно, неудобно.Кстати, можно и без прокси. Просто писать отдельно кеод для сервера, а отдельно для клиента. Верно же будет, что мод, лежащий на клиенте, это всегда клиентская часть. А его вторая половинка - серверная. Тут даже прокси не нужны. Только правильно делить
Слушай сначала я думал, что ты просто тролишь. Кажется все же нет.Прокси юзаются, что склеить общую часть с клиент/сервером. Причём так склеить, что эта самая общая часть не будет зависеть ни от клиента, ни от сервера.