Ахах, немного жиза, спасибо)

Одна из любимых игр)

@@NightTrainCode так же)

Не увидите, это та вещь которая нарабатывается только опытом с годами 🤷

Ахахахха, с "учимся открывать юнити за час" орнул) Спасибо большое за теплые слова 😉

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

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

@@artsurock Все мы проходили чем море ужасного контента по юнити на ютубе... Abstract - обширная тема (но самом деле очень простая), а ключ readonly разрешает устанавливать значение полю только через конструктор, либо через оператор равенства при её объявлении

@@NightTrainCode а разве в unity нет конструктора?

Хотел бы дополнить, что декоратор как раз отвечает за принцип открытости-закрытости. Так как он расширяет функционал основного класса без его изменения.

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

Спасибо большое, рад помочь)

Спасибо большое) На здоровье

На здоровье, спасибо)

Спасибо, рад помочь)

На здоровье, спасибо большое)

На здоровье)

Большое спасибо, на здоровье! А мне очень приятно читать Ваш комментарий) Ахах, значит мне надо и дальше вносить разнообразие в видео вставками из жизни, если они в тему 😄 Кстати, я с такими мыслями и делал ту вставку, что Вы описали в постскриптуме)

​@@NightTrainCode Буду и дальше радовать Вас комментариями, просмотрами и лайками :3 Уже порекомендовал ваш канал нескольким знакомым. Теперь уже не только мне одному интересно, чему вы будете нас учить в следующий раз! Я рад, что ваша вставка оказала именно тот эффект, который вы закладывали. Признаюсь честно, в какой-то момент появилось желание поучаствовать в том веселье :)

@@dzammboo Спасибо большое, безумно благодарен) Ахах, будете в Красноярске, залетайте к нам на дачу 😹

@@NightTrainCode Спасибо) Обязательно сообщу, как буду проездом! :3

@@dzammboo Окей)

Синхронизация

Спасибо)

Ахахахах)

Спасибо)

Ой, а как это меня на собеседование угораздило?) 1. Нет, потому что оружие на то и оружие, чтобы у него была обычная атака 2. По такой логике можно класс Microwave разделить на классы EnableMicrowave, DisableMicrowave и т.д., а это маразм)

И благодарю за интересные вопросы)

@@NightTrainCode а это не собеседование ) А вопрос ко всем: где та грань единственной ответсвеннности? Именно в этом и подвох: порой принцип единственной ответсвенности возводят в абсолют, а порой трактуют слишком широко.

@@HizusHiz А никто не знает) Кто как хочет, так и...

@@NightTrainCode Я себе в этом плане всегда задаю вопрос на перспективу: потребует ли бизнес (или геймдизайнер, если говорить про игры) в рамках конкретной сущности каких либо изменений или потребуется альтернативная сущность? Ответ на этот вопрос дает понимание, где надо вводить принцип единственной ответсвенности... Хотя и не всегда удается "угадать" ))

Спасибо большое)

You're welcome, thank u)

Можно)

Ахах, ага. А ещё принципы KISS и PIDOR)

На здоровье) По про билдеру не планировал, год уже им не пользовался, но в идеи для видео запишу

Купить в ассет сторе)

Виталя, фейсит пошли

Спасибо) Да, верно! Пожалуй, удалю видосик 😹

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

Начнём с того, что там у нас не публичные поля, а публичные свойства. Разницу можете почитать в интернете :) А пихать логику Damageable и DrawHealth в класс UnitHealth - вот это, случайно, не нарушение принципа о единой ответственности?)

А ООП запрещает нам пользоваться событиями или я чего-то не знаю?

@@NightTrainCode 1. Это вообще не играет роли. Любые паблик поля, как бы вы их не называли, протектед, не протектед, они сообщают информацию об объекте, грубо говоря разглашают его состояние. Это нарушение инкапсуляции. Объект не должен делиться своим состоянием, так как внешний код будет на него завязываться и это будет нарушать SRP, так как уже внешний код, прямо как у вас в примере будет заниматься тем, что будет изменять состояние объекта напрямую, а не через регламентированный метод. Если для вас это не проблема, то вы дилетант и скорее всего выше чем на джуна вас не возьмут. 2. Когда мы даём нашему объекту Health метод DrawHealth, а в параметр передаём ссылку на объект, которому нужно сообщить об изменении, никакой ответственности по отрисовке класс не берёт, он только сообщает значение объекту, который занимается выведением значения. Тут всё ровно. Объект который рисует передаётся в ссылке, а здоровье только уточняет что именно отобразить, при этом не раскрывая своё состояние внешнему классу.

@@YooPita Ок)

Это будет фиаско