УБЕРИ ЭТО из архитектуры игры! C# и Unity! 5 ошибок в построении архитектуры

แชร์
ฝัง
  • เผยแพร่เมื่อ 29 ก.ย. 2024

ความคิดเห็น • 106

  • @-it394
    @-it394  9 หลายเดือนก่อน +2

    ⚡⚡⚡ Полезные ссылки ⚡⚡⚡
    🔎 yakovlevgamedev.ru - курс по архитектуре игр в Unity
    🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал (тут розыгрыш и материалы для обучения со всеми полезными ссылками - искать в закрепленном сообщении)
    🔎 dzen.ru/b/ZVthaYMiXVQbRmWa - статья про LinQ от Лавки разработчика
    🔎 boosty.to/yakovlevgamedev - ссылка на бусти
    🔎 th-cam.com/channels/C-hfECZdghe_QNAJzztHEg.html - ссылка на канал моего младшего брата (подпишись если не сложно)

  • @flexmachine2280
    @flexmachine2280 9 หลายเดือนก่อน +84

    Кто ничего не пишет, тот не ошибается в коде☝️🧐

    • @megammmarisnowflake8623
      @megammmarisnowflake8623 9 หลายเดือนก่อน +8

      Это яндер дев так делает

    • @emeil1989
      @emeil1989 9 หลายเดือนก่อน

      Ауф

    • @Frogi02
      @Frogi02 9 หลายเดือนก่อน

      ☝️🤓

    • @zeronim1965
      @zeronim1965 9 หลายเดือนก่อน

      Как следствие, тот кто пишет хоть что нибудь, заведомо пишет ошибочный код.

    • @ilhanilhanDev
      @ilhanilhanDev 9 หลายเดือนก่อน

      ​@@megammmarisnowflake8623зато миллионы бухает , в отличий от тебя и от меня тоже

  • @hordorsok
    @hordorsok 9 หลายเดือนก่อน +10

    Спасибо, за видео! Очень полезная информация!

  • @urod7149
    @urod7149 9 หลายเดือนก่อน +1

    спасибо

  • @hackermann99
    @hackermann99 8 หลายเดือนก่อน +1

    Видео не соответствует своей теме. В нём вовсе нет ничего про архитектуру, зато есть короткий список из ошибок новичков в языке С#

  • @argon9113
    @argon9113 9 หลายเดือนก่อน +6

    Мне лень проверять НО, 1:27 идея с заменой на свойство может быть опасна, поскольку Vector3 является структурой и будет создана копия, редактирование которой никак не изменит исходный объект

    • @-it394
      @-it394  9 หลายเดือนก่อน +3

      Так я и не редактирую, а просто обращаюсь. Но, в целом да, замечание верное, за этим надо следить)

    • @dmitriytuchashvili8594
      @dmitriytuchashvili8594 9 หลายเดือนก่อน

      Я привык думать о лямбда выражениях такого типа как о сокращениях, или ссылках на что-либо. То есть под капотом свойство Position ничего не хранит. Это просто проводник, который за ручку нас ведет к другому полю или методу. В данном случае к transform.position

    • @lit1041
      @lit1041 9 หลายเดือนก่อน

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

  • @Kompreso
    @Kompreso 9 หลายเดือนก่อน +1

    5:26 в конструкторе базового класса уже создаётся лист, о чём речь вообще?

  • @Максим-ъ6о6п
    @Максим-ъ6о6п 3 หลายเดือนก่อน

    Все виконано на принципі чистого коду по суті, який архітектуру гри сповільнить як і всі інші аспекти коду.

  • @ИванИсайков-я5с
    @ИванИсайков-я5с 9 หลายเดือนก่อน +3

    Не советую удалять абстракцию "сделанную для красоты", если планируете в будущем систему модификации игры, иначе придётся дофига всего переписывать...

  • @volodya185
    @volodya185 9 หลายเดือนก่อน +3

    Касательно второй ошибки:
    Как метод назовёшь, так его и будут использовать, назови нормально и переопределять не будут, но в целом практика действительно хорошая, абстрактные и виртуальные поля лучше не вызывать в конструкторах. Что касается ошибок в конструкторе, для такого лучше использовать статический метод Create, что тоже частично нарушает паттерны, но лучше ошибок в конструкторе. Есть ещё предложение создавать методы Init и подобные, чтобы этот метод вызывали при необходимости, и вот он может выкидывать ошибки, а конструктор пусть будет.
    Касательно 4-ой ошибки:
    Не считаю это ошибкой, ведь ты сам объяснил, почему это хорошо, иногда это рудимент. Хотя конечно лучше задуматься над тем, где какие интерфейсы нужны, а где они бесполезны. И если мы говорим про предметы, которые можно собирать, лучше сделать интерфейс типа IStorable, если есть предметы, которые можно со стакать, можно назвать ICollectable. В целом согласен с твоим тезисом.

  • @craftgameworld
    @craftgameworld 3 หลายเดือนก่อน

    Последняя ошибка не до конца раскрыта)
    Как назвать метод, в котором будет следующий код "if (IsWinning()) {ShowVictoryWindow(); ShowVictoryParticles(); ... }" ?

  • @kirillsviderski4739
    @kirillsviderski4739 9 หลายเดือนก่อน

    1:24 оочень вредный совет. Зачем нам три раза оди и тот же вектор копировать? И почему-то многие юнитисты в погоне за "чистым кодом" допускают такие ошибки
    А через пару секунд како-то мракобесие с форматированием в апдейте
    2:40 можно просто рассказать про First class collection - очень полезный принцип в целом
    4 ошибка - жизааааааааааа. Люди с гиперкежа ооочень любят клепать абстракции, которые вообще не нужны. Люди не умеют итерировать просто и их потом не перучить делать большие фичи в "больших" играх
    5 - просто база

  • @uuuummm9
    @uuuummm9 8 หลายเดือนก่อน

    Всё круто, только плз давайте не будем называть это громким словом "архитектура". Это просто вопросы дизайна уровня чуть выше микро. Из-за того, что вот это называют архитектурой, потом на проекте куча архитекторов и ни одного кодера. Все только и делают, что языками чешут.

  • @АлександрСериков-ч5ю
    @АлександрСериков-ч5ю 2 หลายเดือนก่อน

    Заголовок "5 ошибок в архитектуре".
    Реальность: переименовываем переменные для лучшей читаемости...

  • @ИгорьФилатов-и1к
    @ИгорьФилатов-и1к 9 หลายเดือนก่อน +3

    Свойства - это просто другая форма (синтетический сахар) вызова get и set методов, со всеми вытекающими. Не всегда происходит инлайн оптимизация, стоит обращать внимание на частоту вызовов, но в рамках игровой логики маловероятно, что где-то будете упираться в производительность.
    Насчет запрета исключений в конструкторе - эта проблема из плюсов, на си шарпе просто как правило хорошего тона.
    Linq имел проблемы с производительностью во времена четвертого юнити, сейчас там больших проблем нет, и тогда же я не рекомендовал его использовать так как не все понимали его (редко использовался), что тормозило задачи. Сейчас с этим проблем нет, в клиент-серверном это стандарт, а следить за выделением памяти так и так придется, всегда можно поправить.

    • @ravenempty3562
      @ravenempty3562 หลายเดือนก่อน +1

      Не синтетический, а синтаксический)

  • @gladiko2364
    @gladiko2364 8 หลายเดือนก่อน

    Ошибка номер 0: пихать лямба выражения в каждую строчку, что бы побольше в код насрать.

  • @skalse4184
    @skalse4184 9 หลายเดือนก่อน +1

    1. Это не ошибка, а более фича, что ли удобство.
    2. Тоже фича и под конкретную задачу, нет смысла лишний раз делать переменные так-то.
    3, 4 и 5 согласен полностью

  • @holo2028
    @holo2028 9 หลายเดือนก่อน +2

    Прикольное видео наверно, жаль что я пока что далёк от понимания этого)..

  • @civilontrol2139
    @civilontrol2139 7 หลายเดือนก่อน +1

    Причем тут архитектура?))

  • @arturkadirov9280
    @arturkadirov9280 9 หลายเดือนก่อน

    Честно, понял меньше половины... Пойду книжки читать... Опять...

  • @весёлыйджек-у4щ
    @весёлыйджек-у4щ 9 หลายเดือนก่อน

    Хорошо, теперь куда выкладывать игры во время санкций в России?

  • @ivanfilatov5482
    @ivanfilatov5482 5 หลายเดือนก่อน +1

    вкусовщина

  • @RimuruDev
    @RimuruDev 9 หลายเดือนก่อน +4

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

    • @FloatingGames
      @FloatingGames 8 หลายเดือนก่อน

      А на чем сервер? На сокетах?

    • @RimuruDev
      @RimuruDev 8 หลายเดือนก่อน

      ​@@FloatingGamesКурс кстати купил, скоро начнутся занятия. А что насчет вопроса, сам сервак на Ubuntu хостится, само собой использую Docker контейнер. Серверная логика игры на NakamaServer + TypeScript. Клиент очевидно Unity + C# ;3

    • @FloatingGames
      @FloatingGames 8 หลายเดือนก่อน

      @@RimuruDev я впервые такое слышу, у меня сервер на windows + c#, а зачем используют docker? Просто сколько не спрашивал у всех невменяемый ответ

    • @RimuruDev
      @RimuruDev 8 หลายเดือนก่อน

      @@FloatingGames Странно что у “всех” невменяемый ответ :3
      Тогда постараюсь сказать в двух словах и максимально просто.
      Докер помогает "упаковать" приложение со всеми его настройками и зависимостями, чтобы оно могло легко и одинаково работать на любом компьютере или сервере. Это существенно упрощает развертывание и управление приложениями, делая разработку более гибкой и эффективной.
      Допустим теперь понятно вкратце чем хорош докер. Но теперь вы подумали “нафига оно мне???”.
      Без Докера: Если вы разрабатываете на Windows с C# (судя по комментарию), ваше приложение может не работать или работать по-разному на других системах (например, Linux), из-за различий в настройках и зависимостях.
      Если даже после этого ничего не понятно, то лучше глянуть отдельно материалы о том для чего нужен докер и чем он полезен. Так как я плохо объясняю :3

    • @FloatingGames
      @FloatingGames 8 หลายเดือนก่อน

      @@RimuruDev а вообще на Линукс можно скомпилировать c# проект, просто мы пытались это сделать но никак не получилось

  • @mrgates231
    @mrgates231 9 หลายเดือนก่อน +5

    Архитектура слишком сильное слово для таких ошибок уровня "первый раз открыл юнити"

    • @zjcom-bb7ek
      @zjcom-bb7ek หลายเดือนก่อน

      По логике чем выше уровень программиста, чем меньше он ошибок совершает. Так что вряд ли существует понятие "ошибки профессионалов"

  • @prototypelq8574
    @prototypelq8574 8 หลายเดือนก่อน

    Видео интересное, но от Чaracter ушкам больно

  • @miefis
    @miefis 3 หลายเดือนก่อน

    Ваще нихуя не понял
    Можно про ошибки в коде у новичков

  • @Иван-д2ф6ш
    @Иван-д2ф6ш 9 หลายเดือนก่อน +1

    а что вот этот значок делает => почему нельзя просто = поставить
    ?

    • @-it394
      @-it394  9 หลายเดือนก่อน +2

      Это лямбда выражения
      metanit.com/sharp/tutorial/3.16.php - вот тут можешь почитать)

  • @cimweed18
    @cimweed18 9 หลายเดือนก่อน +1

    Абстракции для красоты( Нашел парочку

  • @dixis1908
    @dixis1908 8 หลายเดือนก่อน

    Кек, ничего из этого не допускал хД

  • @VoroninPavel
    @VoroninPavel 9 หลายเดือนก่อน

    Лучше вообще выкрутить все ворнинги до ошибок. И отключать их локально или глобально, снабжая осознанным вменяемым комментарием, почему здесь такой код ОК.
    Тогда, например, и с виртуальным методом в конструкторе (2 ошибка) не накосячить.
    Еще, кстати, хорошо завести привычку объявлять классы как не наследуемые по умолчанию. Тут и IDE чуть быстрее работать будет, и глазкам сразу видно, что наследников у типа точно нет.

    • @FloatingGames
      @FloatingGames 8 หลายเดือนก่อน

      Типа sealed?

    • @VoroninPavel
      @VoroninPavel 8 หลายเดือนก่อน

      @@FloatingGames угу

  • @questprom
    @questprom 9 หลายเดือนก่อน +1

    нашёл 2 метода с check в начале, убирать не буду, мой код - мои правила ))

    • @-it394
      @-it394  9 หลายเดือนก่อน +1

      🤘🤘🤘

  •  9 หลายเดือนก่อน +1

    Интересно узнать.
    У меня рогалик, уже 10 месяцев в разработке, через месяц финал.
    Персонаж состоит из кучи стат, айтемы улучшают их. Я реализовал это через Scriptable Object, создал массив где SO инстанциируется и получается новый SO, который при изменении не повлияет на оригинал. К его полям всегда есть доступ через эту датабазу на чтение и запись, они просто публичные.
    Это плохая реализация?
    Пока я не сталкивался с проблемами на всём пути разработки и удобно изменял значения, а где они делились или уходили в минус я делал проверки и задавал значение.
    Типа если МаксХП после айтема

    • @-it394
      @-it394  9 หลายเดือนก่อน +2

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

    •  9 หลายเดือนก่อน

      @@-it394 А что за видео по архитектуре? Хотя лучше посмотрю все)
      В принципе, я тоже самое могу сделать и классами и получать доступ в ним, но это придётся работать больше)
      Для начала (да и я тогда вообще ничего не знал, а рекомендовали SO очень для стат, но не уточняли что их используют как конфиги) я считаю норм :D Всё равно я был уверен что в будущем буду переписывать всё красиво и нерушимо, насколько это возможно.
      Часто было такое что враг получал двойной урон, пофиксил временем неуязвимости, которое тоже может быть 0 и меня в принципе устраивает.
      Меня харило писать сначала SO, добавлять туда новую стату, потом добавлять её же в класс с ними, а ведь игрок должен свои данные засэтить из него, получается третий раз, аналогично с врагами, ибо им один SO не дашь.
      Вот что реально выстрел в ногу - я не могу таким образом добавить в будущем кооп, ибо всё через SO, а два таких сделать анриал, ибо всё сломается. Не думал что буду делать кооп, а он вписывается вообще.
      Так что убирать буду, теперь точно :D
      Спасибо за ответ и видосы

    • @FloatingGames
      @FloatingGames 8 หลายเดือนก่อน

      ​@разве so создавался для того чтобы записывать в него данные?

  • @tugoshow2049
    @tugoshow2049 9 หลายเดือนก่อน +1

    Мне понравился ролик про ошибки 👍. У меня с усложнением кода всегда проблема была, надеюсь исправлю. Я бы хотел вторую часть 😅

  • @ilhanilhanDev
    @ilhanilhanDev 9 หลายเดือนก่อน

    С первым интересно , остальные будут более мешать чем кодить . Когда ты хочешь описать механику и за одно думаешь как это лучше прописать ,чтоб на скрипте смотрелся лаконично, это во первых отбивает желание кодить, сбивает с толку, отнимает время, и возможно с большим процентом ты не сможешь выполнить задуманное.
    Я говорю механиках придуманной из головы (ответ который в инете не нашел), а не шаблонные механики(которые уже прописанны для тебя сотни раз)
    Вообще проще саздовать второй велосипед и гавнокодить просто надо учесть:
    Много ифов не добавляйте производительность жрет, говорят кейсом проще или ифелсом пользуйтесь если ра то пошло. P.S. YandereDev
    Делайте так чтобы коды можно было друг от друга отстыковавать, механики, чтобы по блокам по честям, можно было кодить или даже сносить и менять опрелеленную механику если это захочится

  • @apogee...
    @apogee... 9 หลายเดือนก่อน

    Я вот разве что первую ошибку совершаю... просто потому что все остальные ошибки я даже не смог бы совершить) Что за интерфейсы, что за виртуальные воиды, каво?
    Разве что хотел бы спросить
    Что означает вот это {get, set} после переменной? Возможно это что-то крутое, что мне стоило бы использовать
    Я только вчера узнал про "=>" и блин, это так удобно

  • @JamesListener
    @JamesListener 9 หลายเดือนก่อน

    Секундочку. На 1:50 ты же задаешь луч значением по умолчанию, т.е. он будет сгенерирован при создании объекта. А в апдейте ты рейкастишь всегда один и тот же луч! Некорректный пример же.

  • @opodlinok
    @opodlinok 9 หลายเดือนก่อน +2

    Про отказ от бессмысленных переусложнений -- лучший совет. Иногда открываешь код (допустим когда тестовое при приёме на работу проверяю), а там такие приколы... Интерфейсы и абстракции ради красоты ещё никому лучше не делали.
    Единственное чего придерживаюсь в плане, что не всегда оно нужно -- в каждом новом проекте создаю интерфейсы
    IInitializable { Initialize(); } и
    IConstructable { Construct(T param); }
    Как раз для решения проблемы с тем, что конструкторы только для инициализации полей. Можно писать по типу new ClassName(инициализируемые поля).Initilize(), а Construct использую для монобехов (awake и start только в бутстрапе или декоративных элементах не влияющих на логику игры).
    И сразу видно, если с классом после создания, перед выполнением его логики, нужно провести ещё какие-то подготовительные операции.
    Видео отличное и очень полезное! Спасибо С:

    • @_Otets_
      @_Otets_ 9 หลายเดือนก่อน +5

      Вообще паттерны и всю эту херобору, вплоть до DI нужно использовать только когда это нужно. Я вообще со временем пришел к выводу что сначала лучше наебошить код в лоб, а уже потом, как только появляется такая необходимость переписать. Ибо эти пресловутые BP без надобности превращают код в кашу из кучи интерфейсов, мелких методов на пол строки и остальных приколюх. Я иногда даже юзаю простой инициализатор вместо Zenject.

    • @opodlinok
      @opodlinok 9 หลายเดือนก่อน +1

      @@_Otets_ это если ты работаешь соло или не в коммерческой разработке и твоим кодом не будут заниматься другие люди

    • @_Otets_
      @_Otets_ 9 หลายเดือนก่อน

      @@opodlinok Ну нет, когда ты делаешь прототип как раз в команде самая лучшая стратегия - это фигачить как фигачится: сущностей мало, зависимостей тоже. Это уже когда прототип идет в работу и окончательно ясно чего и сколько будет уже можно писать как по учебнику. А сразу наращивать интерфейсы ради 2-ух с половиной калек - такое себе. Ну и офк, стоит упомянуть что я работают с мобилками в тиме из 4-7 человек.

    • @karimkimsanbaev7932
      @karimkimsanbaev7932 9 หลายเดือนก่อน

      То есть это просто интерфейсы для учёта инициализируемых классов? Какую это задачу решает? Можно без интерфейсов писать. И в Construct если несколько параметров - не создавать лишний объект. Нет лишнего объекта - не надо лишнего поддерживать.
      Наверное, если есть Initializable, то есть и Disposable?

    • @opodlinok
      @opodlinok 9 หลายเดือนก่อน

      @@karimkimsanbaev7932 констракт вообще не используется при создании объекта. Это буквально функция для подготовки монобеха без awake/start к работе.
      Эти интерфейсы решают задачу унифицирования кода - ты, конечно, можешь просто прописывать в каждый класс функцию Initialize со своей логикой и без интерфейса, но смысл если можно одним кликом её реализовать, да и к тому же показать всем, кто работает с этим классом, что его мало просто создать, но и перед работой нужно что-то сделать, с первого взгляда

  • @KingDragon_Channel
    @KingDragon_Channel 9 หลายเดือนก่อน

    Здравствуй, не интересна ли тебе идея снять ролик по кривым?

  • @petrpal330
    @petrpal330 9 หลายเดือนก่อน

    Последний совет про то, как лучше заменить Check - очень кстати, спасибо) Давно была мысль как-то симпатичнее организовывать этот момент.

  • @ilya.drone.moments
    @ilya.drone.moments 8 หลายเดือนก่อน +2

    а меня например напрягают люди пишущие название полей через _ , считаю это ошибкой - не допускай этого. А если серьезно, в целом по делу тут мало чего, человек который смог написать большой и стабильно работающий проект (в данном случае игру) и с возможностью без проблем его дорабатывать - сделал все правильно. И нет такого понять "Не надо так делать", раз сделал - значит надо было

    • @timothypsina
      @timothypsina 8 หลายเดือนก่อน

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

    • @ilya.drone.moments
      @ilya.drone.moments 8 หลายเดือนก่อน

      @@timothypsina я написал комментарий в окнтексте видео, а из того что сказано в видосе, это никак не вредит легкости и поддержанию проекта. Но громко заявляется как "Ошибка - которую не стоит допусткать"...

  • @ДмитрийГуляев-н5н
    @ДмитрийГуляев-н5н 8 หลายเดือนก่อน

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

  • @MrYuriyP
    @MrYuriyP 9 หลายเดือนก่อน

    Эти советы полезны в любом проекте, а не только при разработке игр.

  • @johnwheel2591
    @johnwheel2591 9 หลายเดือนก่อน

    4 ошибка топ. Сам этим страдаю. Правдивая до жути

  • @bogdangaranenko2130
    @bogdangaranenko2130 9 หลายเดือนก่อน

    Кликнул из-за юнити, но тут базис по шарпу

  • @igor_mutny
    @igor_mutny 9 หลายเดือนก่อน

    И свойствами толком не умею пользоваться (1-я ошибка), и в конструкторы всякую хрень пихаю (2-я ошибка). LINQ не пользуюсь, - как-то не возникало необходимости. 4-я и 5-я вроде ко мне не относятся 😅

    • @kirillsviderski4739
      @kirillsviderski4739 9 หลายเดือนก่อน

      Почитай начало статьи от Grammarly под названием Declarative Programming in .NET.

  • @omegakrakengames
    @omegakrakengames 9 หลายเดือนก่อน

    Я почти мегамозг )
    Спасибо за видео

  • @dicony3427
    @dicony3427 9 หลายเดือนก่อน

    Очень познавательно, требую еще)

  • @fisashgames6704
    @fisashgames6704 9 หลายเดือนก่อน

    полезный видос

  • @psix2006
    @psix2006 9 หลายเดือนก่อน

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

    • @FloatingGames
      @FloatingGames 8 หลายเดือนก่อน +1

      Тогда лучше будет сначала изучить теорию, говорю как разработчик 3года и особо ничего не знающий, буду после этой сессии жёстко учиться

    • @ilya.drone.moments
      @ilya.drone.moments 8 หลายเดือนก่อน +1

      без нормального кода, что-то сложнее раннера ничего не напишется

  • @alsg00
    @alsg00 8 หลายเดือนก่อน

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

    • @-it394
      @-it394  8 หลายเดือนก่อน

      Я наверное неудачно сделал нейминг) И в родительском и в дочернем классе свой приватный список, который я назвал и там и там list. Поэтом в дочернем классе мы пишем в свой список, который ещё не проинициплизирован

    • @alsg00
      @alsg00 8 หลายเดือนก่อน

      Нет-нет, по неймингу всё понятно, вопрос немного в другом. В видео говорится, что при создании экземпляра дочки сначала вызывается конструктор родителя. А родитель в своём конструкторе обращается к СВОЕМУ виртуальному методу, в котором идет обращение к СВОЕМУ приватному списку, который уже проинициализирован. А если он проинициализирован, то почему должна возникнуть ошибка? Или виртуальный метод к моменту вызова уже перезаписан дочкой?

    • @-it394
      @-it394  8 หลายเดือนก่อน +1

      Уже перезаписан (сначала вызывается дочерний метод, потом через base. родительский)@@alsg00

  • @cristalGamer5100
    @cristalGamer5100 9 หลายเดือนก่อน

    Протектед же имеет те же уязвимости что и публичный уровень доступа?

    • @-it394
      @-it394  9 หลายเดือนก่อน

      Можно по подробнее к чему этот вопрос?)

    • @timothypsina
      @timothypsina 8 หลายเดือนก่อน +1

      Protected является рекомендацией по правилу SOLID "открыт к расширению, но закрыт к изменению", так этот модификатор доступа и работает.

  • @maksimsazanovich6087
    @maksimsazanovich6087 9 หลายเดือนก่อน

    Можно я кота-яковлева в игру добавлю?)

    • @-it394
      @-it394  9 หลายเดือนก่อน +1

      Не знаю что за игра, но звучит забавно😂

    • @maksimsazanovich6087
      @maksimsazanovich6087 9 หลายเดือนก่อน

      @@-it394 , потом на скриншот сатурдей покажу

  • @Kitsikoo
    @Kitsikoo 9 หลายเดือนก่อน

    Чарактер. Ясно понятно. Зовите следующего...

  • @daniilsamodurov5423
    @daniilsamodurov5423 9 หลายเดือนก่อน +1

    насчёт первой ошибки - мне кажется, в основном это только для себя упростит жизнь - в случае чего другому программисту будет только сначала визуально комфортно, но потом на каждое такое нажимать и разбираться что это (а это обычный transform.position) не очень удобно
    но в принципе если на такие банальные штучки не делать (ну или уж слишком часто оно встречается, то можно)

    • @-it394
      @-it394  9 หลายเดือนก่อน +1

      Это довольно простой пример, но если адекватно называть все и убирать что- то длинное в свойства, то жизнь упрощается всем)

    • @_Otets_
      @_Otets_ 9 หลายเดือนก่อน +2

      Ты еще не забывай что такое свойство- это и кеширование.

    • @volodya185
      @volodya185 9 หลายเดือนก่อน

      Я бы сказал, что лучше это не в ствойства делать, а в переменные в методе кидать, если часто вызывается, лучше создать приватный метод GetSth

    • @karimkimsanbaev7932
      @karimkimsanbaev7932 9 หลายเดือนก่อน

      Потом юзинги по проекту собирать, ну уж нет)

  • @xpoftik
    @xpoftik 9 หลายเดือนก่อน

    Постоянно тыкаю моих подопечных на проекте в подобные ошибки. Всё это нарабатывается только с опытом. Потом уже просто на автомате действуешь правильно. Советы на самом деле полезные! 👍

  • @justlama0
    @justlama0 9 หลายเดือนก่อน

    за такие Awake методы надо руки отбивать

    • @-it394
      @-it394  9 หลายเดือนก่อน

      В плане?