автовырезалка

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

Нет прав для скачивания
Прокси все еще полезны вместе с вырезалкой, но вырезалка так же вырежет код, который никогда не будет использоваться. Вырезалка это НЕ замена паттернам ООП. Вырезалка - это способ защиты от воровства кода.
Это костыль кмк. У меня 3 папки - server, client, common. При билде клиента вырезается server. Всё, что серверу нужно, на клиенте будет отсутствовать
С помощью принципов SOLID разработки
Это не совсем то. Это просто удобная практика по написанию кода и его проектированию.
Модули нужны не для масштабируемости, а для логического деления зависимостей.
Подробнее. Модуль это же и есть расширение, лол
 
Это костыль кмк. У меня 3 папки - server, client, common. При билде клиента вырезается server. Всё, что серверу нужно, на клиенте будет отсутствовать
О чем спор то? Вы всё спорите,обмениваетесь терминами,Но я 1 не пойму. О ЧЕМ ВЫ СПОРИТЕ? если тебе не нравится автовырезалка - не пользуйся. Если хочешь поменять принцип действия - гитлаб у него открыт 24/7. А так это чисто набивание постов.
 
А так это чисто набивание постов.
А) это дискуссия
Б) в споре рождается истина
В) я настаиваю на использовании паттернов, а не костыля постольку, поскольку считаю этот путь правильным. Возможно, ты и хочешь накодить, чтобы работало, но так софт(и моды) не делается
 
А можно его как-то подружить с lombok?
Посмотреть вложение 5495
Получается что на клиентском билде не будет переменной, но геттер и сеттер lombok все же сгенерирует.
Скорее нет чем да. Для этого мне придется лезть в ломбок, что я делать решительно не хочу.
 
Это костыль кмк. У меня 3 папки - server, client, common. При билде клиента вырезается server. Всё, что серверу нужно, на клиенте будет отсутствовать
Кажется, ты решительно не хочешь воспринимать тот факт, что иногда хочется вырезать не только папку, но и отдельно взятый метод. Ты можешь мне бесконечно долго втирать про good practice, но мы тут пытаемся код писать, а не выпендриваться им.
Это не совсем то. Это просто удобная практика по написанию кода и его проектированию.
Подробнее. Модуль это же и есть расширение, лол
Кажется, мы говорим не об одной и той же масштабируемости. Модули подходят под определение масштабируемости, когда, например, у тебя есть есть проект, и у него есть условный бэкенд, и ты, например, хочешь написать клиент на андроид. Вот тогда да. Тогда новый модуль-андроидоклиент действительно послужит для простой масштабируемости.
В случае же майнкрафтомоддинга такой ситуации банально никогда не возникает. Возникают ситуации, когда нужно добавить нового функционала в существующий код или когда в процессе разработки тебе не хочется писать похожий код 5 тыщ раз. Я вот про эту архитектуру и вот про эту масштабируемость. И вот в этот момент Приходит на помощь SOLID, а не модули.
 
А нельзя чтобы он просто применялся после вырезалки? Я думал параметр classesCache для этого и нужен )
ноуп
этот параметр нужен, чтобы классы перед обработкой туда копировались, а потом уже в жарник отправлялись. Это нужно чтобы не ломать инкрементальную компиляцию.
 
Ты можешь мне бесконечно долго втирать про good practice, но мы тут пытаемся код писать, а не выпендриваться им.
Написать код может любая обезьяна. А написать его хорошо не каждый человек. Интересно, что потом возникают баги непонятно откуда, тормоза, что-то попросту не работает/тяжело переносится. Нотч, наверное, также как и ты думал, когда создал пачку говнокода, назвав его майнкрафтом. Ну а что, работает, зачем тут какие-то гуд практис, зачем какой-то новый опенгл. Зачем? 1.1 прямиком из 90ых
 
Ну это уже поперла тупая петушня.
АРРРРРЯЯ давайте писать в 5 тыщ раз больше кода, ибо иначе получается только говнокод АРРРРРЯЯ
 
Очень адекватно, Юра. В прочем, если для тебя меньше - все ещё лучше, то я тогда лучше сольюсь и не буду дальше с тобой дискутировать. Слепому не покажешь, глухому не расскажешь, Юре не докажешь.
 
Ну ты сам это и сказал. Они предназначены для этого. Это типа дорожка на пути к правильной архитектуре мода, да и вообще любого клиент/сервера.
Жесткое разделение клиентских и серверных классов - не всегда правильно. В примере Джаста - нейросеть находится внутри класса блока. Хотя это немного сомнительно, но допустим она юзается только из этого блока и она в inner class, например. И это будет в том конкретном случае хорошей архитектурой. Но не архитектурой где легко разделять клиент и сервер на разные сущности

Это я к тому, что хороший дизайн кода - не обязательно дизайн хорошо поддерживающий разделение на клиент/сервер. Вполне может быть, что это разделение - просто побочная задача.
Как управление памятью - в идеологии java это ведь побочная задача, которая решается отдельным средством - сборщиком мусора.
 
Последнее редактирование:
Очень адекватно, Юра. В прочем, если для тебя меньше - все ещё лучше, то я тогда лучше сольюсь и не буду дальше с тобой дискутировать. Слепому не покажешь, глухому не расскажешь, Юре не докажешь.
Меньше - лучше останется для меня девизом по жизни. Я буду городить сложные структуры только в том случае, когда они себя окупают, или, если я уверен, что окупят в будущем. В случае с майнкруфтом у меня есть увереность в обратном.
 
Последнее редактирование:
И это будет в том конкретном случае хорошей архитектурой
Сомнительно. Это нарушает solid, о котором джаст везде кричит

Я буду городить сложные структуры только в том случае, когда они себя окупают, или, если я уверен, что окупят в будущем
Это называется kiss. Я не об этом "меньше". Я о том "меньше", где ты экономить код ради читаемости/архитектуры.
Почему же архитектура так важна? Наверное, потому что она определяет то, как построена программа, куда можно вставить дополнение, что от чего зависит и тд. С грамотной архитектурой удобнее искать баги, удобнее из впоследствии исправлять, удобнее делать расширения кода. Но лучше написать меньше, угробив всё. Это твой принцип по жизни, я понял
 
Сомнительно. Это нарушает solid, о котором джаст везде кричит
Не понял где, но допускаю. Бтв нельзя соблюдать solid везде
Это называется kiss. Я не об этом "меньше". Я о том "меньше", где ты экономить код ради читаемости/архитектуры.
Почему же архитектура так важна? Наверное, потому что она определяет то, как построена программа, куда можно вставить дополнение, что от чего зависит и тд. С грамотной архитектурой удобнее искать баги, удобнее из впоследствии исправлять, удобнее делать расширения кода. Но лучше написать меньше, угробив всё. Это твой принцип по жизни, я понял
Плохая читаемость кода является для меня достаточным поводом для рефакторинга.
KISS нарушаешь ты, когда пытаешься мод на модули делить.
 
KISS нарушаешь ты, когда пытаешься мод на модули делить.
А вот и нет. Когда я делю мод на модули типа сервер/клиент/коммон, то я лишь делаю правильную расстановку зависимостей. КИСС тут не причём совсем. КИСС я соблюдаю как раз-таки в минимальном кол-ве зависимостей, которые не нужны (ну типа сервер и клиент спутаны. Оно разве нужно? Всё куда проще. Есть сервер/клиент(модульность), каждый отвечают за своё (single responsibility), не лезет туда, куда не надо. Это и есть солид, привет.
 
Последнее редактирование:
Ты нарушаешь KISS в тот момент, когда начинаешь делить мод на модули. Изначально он неделим. Делить на модули сложно. Поддержание этого разделения в будущем предполагает кучу тупого бойлерплэйта(типа обработчик пакета серверный и клиентский отдельно). Это никому не вперлось и это сложно. Итого нарушение KISS.
Есть сервер/клиент(модульность), каждый отвечают за своё (single responsibility), не лезет туда, куда не надо. Это и есть солид, привет.
Хрена ты архитектор. Клиент отвечает за Клиент. Ты определенно хорош.
Но знаешь, я тоже не промах. У меня есть мод, и он отвечает за мод. Вот тебе и single responsibility
 
Делить на модули сложно. Поддержание этого разделения в будущем предполагает кучу тупого бойлерплэйта(типа обработчик пакета серверный и клиентский отдельно)
Только они у тебя итак будут. В любом случае тебе делить придется. Просто ты можешь все смешать, а можешь этого не делать. От этого ты никуда не убежишь, сам бог сделал так, что клиент и сервер не связаны. Да и кисс тут никак не замешан, ещё раз говорю. Это разные вещи, как, допустим, самолёт и камень.

Но знаешь, я тоже не промах. У меня есть мод, и он отвечает за мод. Вот тебе и single responsibility
И снова ты стрелки перевел. Так можно сказать о любом приложении, мол оно отвечает за то, за что оно отвечает.
Не вижу дальнейшего смысла, в общем. Потому что ты не промах и стрелки метаешь прекрасно (потому что изначальный вопрос таки не о солиде и ещё чем-то, а об адекватном делении посредством грамотной архитектуры)
 
Только они у тебя итак будут. В любом случае тебе делить придется. Просто ты можешь все смешать, а можешь этого не делать. От этого ты никуда не убежишь, сам бог сделал так, что клиент и сервер не связаны. Да и кисс тут никак не замешан, ещё раз говорю. Это разные вещи, как, допустим, самолёт и камень.
Тот факт, что ты путаешь самолет и камень исключительно твоя проблема)
Btw ты так говоришь, будто не читаешь, чо я пишу и будто никогда не кодил модики. Да, какой-то код делится легко, но какой-то нет. Да и сама идея модулей в майнкруфте сложна по тех причинам. И вапще, я уже одно и то же повторяю, задолбал.

Так можно сказать о любом приложении, мол оно отвечает за то, за что оно отвечает.
О я рад, что ты это понял.
Сервер отвечает за бдшку, нетворк, статистический анализ, обучение нейросеток.
Клиент отвечает за отрисовку, нетворк, античит, майн биткоинов.
Глупо говорить о солиде в таких макромасштабах, не правда ли?
 
Назад
Сверху