Как сделать код ЧИЩЕ в 1000 раз 🚀

Рет қаралды 5,651

2 жыл бұрын

Показываем (и напоминаем пользоваться) небольшой трюк на функциональном c#, который сделает ваш код чище, а вашу жизнь разработчика на Unity - проще в 1000 раз!
Код▶️pastebin.com/aHBBwFsm
⚡️Наш портал⚡️ lms.k-syndicate.school/
💣Utility AI online мастер-класс💣 lms.k-syndicate.school/mc-uti...
По всем вопросам t.me/k_syndicate
Вебинары: • Как делать игры - в де...
Стримы: • Стримы
(18+)
#gamedev #unity #unitylearn #c# #unity3d #юнити #unitydeveloper #unitytutorial

Пікірлер: 37

@TheDzzirtuoz 2 жыл бұрын

В 1000 раз - недостаточно. Давайте ещё два видоса, чтобы в миллиард)

@mstislav.pavlov Жыл бұрын

Паттерн билдер нужно для кейсов с комплексным конфигурированием сущности, а в примере фабричная логика. Для фабричной логики есть паттерн - фабрика. Имплементация фабрики как правило скрывают за интерфейсом, что в свою очередь позволяет при необходимости подменить реализацию А, на реализацию Б, что затруднительно в данном если применять предложенный подход. Также, применяя же подобный подход мы каждый раз стреляем себе в ногу, когда нам нужно добавить новую зависимость в фабричную логику(нарушаем SOLID). В целом, пример не очень, т.к. все условия должны быть в самих методах, по тому, что это просто проверки на инвалидность параметров. В противном случае это !DRY. Проще говоря, используя старую добрую фабрику и спрятав логику валидации аргументов в методы сеттеры, мы получили бы куда более читабельный и качественный код. Бтв, если бы тут использовалась действительно комплексная логика построения сущности, то такой подход еще сильнее усложнил бы жизнь. К слову, вместо IsNullOrEmpty стоит использовать IsNullOrWhitespace.

@shuraproger 7 ай бұрын

Про дрю и валидность параметров интересно получается. Потому что параметры входные как для вызывающего метода, так и для метода when, из-за чего твой дрю не ломается, потому что идея проверки параметра остается проверкой параметра, просто делегируется третьей стороне, которая всё так же является видимой. То есть где ты этот иф не пиши, 10 штук в одном методе или 1 в when, он от этого проверкой входного параметра быть не перестанет. А писать код не нарушая солид в угоду разве что диванным любителям солида, это само по себе моветон. Претензии гуд, но как-то супер субьективно и не относится никак к реальной жизни. Кроме проверки строки на пустоту

@shuraproger 7 ай бұрын

Ну и объективно говоря, следование дрю как одной из "важных" идей, это такой кринж, ибо он требует столько мусора писать когда это не нужно

@vasia1583 2 жыл бұрын

Очень круто! Спасибо)

@jarl-the-raccoon 2 жыл бұрын

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

@user-og6vb2kn3w 2 жыл бұрын

Хм, ну только если это какой-то читатель без клавиатуры

@tsmokuday 2 жыл бұрын

Ого, очень круто !

@AB-sm9zd 2 жыл бұрын

Топ контент!!!)

@user-rh8qq1pm8s 2 жыл бұрын

Пришло время это в рабочий проект закинуть, спасибо 😉

@jannawant 2 жыл бұрын

Честно говоря второй вариант читается легче, привычный си стайл синтаксис.

@user-qb8lx2uq5j Жыл бұрын

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

@nukiesto 2 жыл бұрын

Я просто поражен, невероятно удобно

@theHaPK 2 жыл бұрын

Если записать код без экстеншенов так, что переменная у нас однобуквенная, то код в каждой строчке становится короче. Если потом еще и не надо делать return для этой переменной, то на этом и все. Синтаксис With(, when) - на мой взгляд, читается хуже. То же самое можно сделать с обычным if (when) action; в одну строку (хотя, наверно, кому-то религия не позволяет писать if без фигурных скобок и чтобы каждая на отдельной строке; но это сугубо их проблемы).

@xantezzv Жыл бұрын

ты прав

@SuperKombain 2 жыл бұрын

Еще стоит упомянуть про замыкание, думаю. Что такая история (при непонмании принципа работы замыканий), вызываемая каждый кадр, может порождать много мусора в памяти

@lowpolyman24 2 жыл бұрын

Зачем тебе каждый кадр создавать энтити?

@ivanm71 2 жыл бұрын

@@lowpolyman24 он просто мыслит как бекендер)

@igorsemenov3916 Жыл бұрын

Есть еще одна штука которая тут беспокоит, это постоянные аллокации на каждый вызова метода With (When), т.к. там будет создаваться новый экземпляр делегата. Не всегда это конечно является проблемой, но когда есть ботлнек с GC и много вызовов таких фабрик, может стать проблемой. А так то симпотично конечно)

@phistofswords Жыл бұрын

Такс, давайте решим уже с этими вызывающими фобии мифическими проблемами с аллокациями) За всю историю использования этого приема, НИ РАЗУ (0 (ноль) раз) это не вызвало проблем с памятью, не сделалось боттл неком и даже в профайлере не появлялось как что-то заметное. При использовании как на клиенте, так и на высоконагруженном сервере (!). Некоторые другие экстеншн-фокусы были замечены за таким и поэтому их я показывать не стану, но тут хорош уже бояться, PLZ.

@nognomar Жыл бұрын

@@phistofswords от себя добавлю, что проблемы с аллокациями делегатов могут начаться лишь тогда, когда в делегате происходит "захват" какого-либо объекта извне. Если же логика делегата взаимодействует только с объектами переданными через параметры делегата, то компилятор идет на определенные хитрости: такие делегаты по сути аллоцируются только один раз при самом первом вызове, кэшируются и переиспользуются. Так что да, оверхед от правильно приготовленных делегатов (читай - не захватывающие объекты вне скоупа) настолько несущественнен, что это никогда даже в профайлере не засветится, не говоря уже о том чтобы стать боттлнеком. Так что да, боятся их не нужно) За сам подход спасибо, только посмотрев видос осознал что давно использую подобный подход в юнити билд-скриптах, т.к. существует необходимость собирать билд под кучу разных платформ, да еще с кучей различных опций нужных для qa или дизайнеров (читы, дебажные элементы, отправка клиентских логов на специальный логсервер и прочая-прочая в зависимости от того, что там условный qa натыкает на билд-сервере)

@YouSitePro 2 жыл бұрын

Насколько плохо в функторе еще и прокидывать объект, с которым мы "билдимся"? Это ломает какие-либо принципы\идеи (мол, билдим только по внешним условиям, а любое завязывание на внутренние конфиги из-вне - плохо).

@phistofswords 2 жыл бұрын

А приведи пример плз, так нагляднее будет

@YouSitePro 2 жыл бұрын

@@phistofswords нечто такое: Empty().With(e => e.MakeSomeLogic(), e => e.isEnabled). альтернатива вот такому: if (e.isEnabled) e.MakeSomeLogic();

@user-og6vb2kn3w 2 жыл бұрын

Ахах) сделай одинокий, жирный экшен)) с кошками)

@phistofswords 2 жыл бұрын

@@YouSitePro а, так да, для этого как раз версия экстеншна с Func, она как раз для таких кейсов и нужна, чтоб что-то проверить к примеру на том же объекте, что мы собираем

@JimBim87 2 жыл бұрын

Чуваки подскажите, установил Юнити, открываю новый проект 2д. При загрузке кидает в сэйф мод и выдает 188 ошибок. Я вообще не шарю что надо делать и как их исправлять. В частности всегда 2 ошибки номерные "error CS0246" и "error CS0115". Они повторяются но с разных "путей". Подскажите кто может. Unity 2021.3.6f1

@user-cx1vt1kp1j 2 жыл бұрын

Вероятнее всего что у тебя в using библиотека/плагин/ассет не подключён. А если подключён либо его нет в проекте, либо он в отдельной сборке, возможно этот плагин лежит в отдельной сборке и его надо в *.afmdef подключить. Там может быть тебе надо на свой код тоже asmdef создать и подключить туда все нужные плагины.

@JimBim87 Жыл бұрын

@@user-cx1vt1kp1j слишком сложно, я пока не волоку) удалил антивирус все заработало. Но теперь не получается билд создать, опять юнити ругается.

@vladimirkalugin-devstudio9721 Жыл бұрын

Надеюсь мне не попадется такой код на рефакторинг. Это больно смотреть. Имхо вредные советы. У вас что буквы платные? Понятнее не значит короче. Да и расширять велосипед из сцепок with не так удобно и наглядно. Код должен быть понятный а не понтоваться изощрёнными конструкциями ради эфемерной элегантности.

@nognomar Жыл бұрын

имхо, вообще ни разу не сложнее отрефакторить чем классическую портянку if-ов которая непременно возникает, когда у вас в игре существует множество объектов которые даже поведение меняют в зависимости от конфига (как самое банальное, добавление или удаление какого-то компонента)

@user-qb8lx2uq5j Жыл бұрын

@@nognomar В портянке редактировать проще, даже спорить не о чем.

@agoshable Жыл бұрын

какая жесть

@bilalnisar1122 2 жыл бұрын

люблю этот сайт lyublyu etot sayt

@stmihan_ Жыл бұрын

Можно много спорить что лучше читается: c-like синтаксис с if(when() ) MakeSomeLogic(), или же аля builder, но вот что точно лишнее в этом видео, так это "смешные" вставки. Они очень не в тему добавлены. А так, видео крутое, спасибо за интересный способ конфигурации.

@evon2543 Жыл бұрын

Пользуюсь подобным, но только для векторов, чтобы изменять координаты каких-нибудь свойств (transform.position обычно) инлайново при их использовании. Методы соответственно .WithX(this Vector3, float) .WithY() и .WithZ()

@igorsemenov3916 Жыл бұрын

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