🔥 Хорошие новости 🔥

Мне на неделе сообщили, что организуется геймджем с призовым фондом в 100к рублей!

Отличная возможность для ребят, которые хотят набраться опыта и, возможно, подзаработать, ну или просто получить удовольствие от создания игр:)

https://www.uralgamedev.ru/ <- ссылочка на страничку с необходимой инфой и регистрацией тут:)

p.s. я не выступаю в роли организатора, просто информирую о полезном для многих мероприятии:)

Дорогие подписчицы, поздравляю вас с 8 марта!
Оставайтесь такими же прекрасными, умными и целеустремленными и пусть в нашем нелегком геймдеверском деле вам улыбнется удача!

С праздником!!! 🌷🥰

P. S. Парни подключайтесь к поздравлениям в комментариях!!!

🔥 Продолжаем серию уроков по асинхронности в юнити! 🔥

Новая часть по продвинутому использованию корутин! Дальше - юнитаски:)

Жду поддержки на новом видосе! Насколько я знаю для ютуба важно время просмотра, поэтому попрошу досмотреть ролик до титров так сказать🥰

смотреть тут - https://www.youtube.com/watch?v=jyogqdzeEH8

Псс, живые люди тут еще есть?)
А то хочется новый видосик залить🔥

🔥 Новый видос на канале! 🔥

https://youtu.be/bisGKyU1Kyc <- смотреть тута

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

Поддержите видос лайком, комментарием и временем просмотра, а с меня новый контент!)

p.s. Проект в комментариях:)

🔥 Новое видео! Начинаем разбираться с реактивностью 🔥

https://www.youtube.com/watch?v=aGr9dGLq5qc - смотреть тут:)

👉 Сильно старался донести все максимально доходчиво, начиная с самого начала) Поэтому надеюсь вы поддержите видос, лайком, комментарием и временем просмотра)

👉 В комментариях лежит обещанный проект с инкапсулированной реализацией примера и небольшая пояснялка

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

Ставьте 🔥 если ждете больше контента:)

🧐 Boxing/unboxing 🧐

Начинаем обсуждать момент, освещенный в последнем видео по реактивности. А именно проблему сравнения объектов, которая там возникает.

Если не смотрели последний видос, то обязательно посмотрите:) Ну и 🔥 поддержите, если интересно

Мы знаем, что все типы в .NET, в том числе value type, такие как float, int и тп. являются неявно унаследованными от класса Object.

Т.е. это значит, что любой объект (неважно value type или reference type) мы можем скастить к типу object без зазрения совести

int number = 42;
object obj = number;

И смотрите в чем тут интересность. Дело в том, что object – это класс, а значит все таки ссылочный тип.

И получается, что я каким-то образом, int, который является структурой, т.е. value type могу засунуть в reference type переменную - как это вообще возможно?

Так вот как раз такой процесс, когда мы value type кастим к ссылочному типу, т.е. процесс преобразования value type значения к reference type и называется упаковкой (boxing).
А когда я делаю обратную операцию, т.е. пытаюсь ссылочный тип скастить к valueType обратно, то происходит распаковка (unboxing)

int number = 42; // Значимый тип
object obj = number; //boxing (упаковка)
int unboxedNumber = (int)obj; //unboxing (распаковка)

И на первый взгляд ничего плохо нет, все работает, компилятор не жалуется, но не все так просто:)

Упаковка и распаковка вызывают накладные расходы по производительности, т.е. магии не происходит. При боксинге в куче выделяется новый объект, в который упаковывается значение, а процесс анбоксинга извлекает тип данных из созданного объекта (фактически создается просто новый ненужный объект в куче каждый раз). Т.е. понимаете, да? Тут все не так просто как при обычном касте тех же классов и частые подобные процессы могут генерировать кучу мусора, которую сборщик мусора должен будет разгрести

Кроме того подобные ситуации возникают и при реализации интерфейсов на структурах, так что надо быть осторожным (но это отдельный вопрос, не будем его пока трогать)

🤓 Так вот кто мне теперь ответит, почему первоначальная версия нашей реактивности с использованием метода Equals для сравнения плохо подходила для практических задач?

Напомню, что выглядела она вот так:

 if(_value.Equals(oldValue) == false)
     Changed?.Invoke(oldValue, _value);

псс, кажется у кого-то сегодня день рождения (да, я люблю загадки)

Спасибо всем, кто остается со мной все эти годы, несмотря на нестабильную подачу контента:))) К сожалению еще не нашел где взять 25-й час в сутках, но я все еще продолжаю поиски

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

p.s. не люблю вот эти штуки про то чего я достиг за год и какой я крутой, лучше поговорим о чем-то более интересном позже на стримах и в отдельных постах - есть некоторые планы на ближайшие недели:)

p.s.s поздравления, конечно же, принимаются😍

🔥 Как правильно сравнивать объекты? 🔥

Продолжаем обсуждение проблем, возникших у нас при реализации реактивности
Кто не читал про боксинг/анбоксинг, то первая часть тут

Как верно заметили в комментариях под предыдущим постом, вот так сравнивать объекты произвольного типа никак нельзя:

 if(_value.Equals(oldValue) == false)
     Changed?.Invoke(oldValue, _value);

Как минимум в таком случае мы сталкиваемся с проблемами боксинга/анбоксинга, т.к. стандартный equals принимает object. И вот вопрос: "А как тогда правильно сравнивать объекты?"

Ответ на этот вопрос - использование интерфейса IEquatable<T>, предназначенного для определения алгоритма сравнения объектов указанного типа. Он находится в неймспейсе System и выглядит так:

public interface IEquatable<T>
{
    bool Equals(T other);
}

Казалось бы, в чем разница с обычным bool Equals(object obj)? А разница в универсальном параметре. Например, если мы при реализации этого интерфейса укажем тип int, то и метод Equals будет принимать именно int для сравнения. И получается, что никакого боксинга в таком случае не будет, т.к. принимается не object, а явно int - это как раз именно то, что нам и надо)

И в реализации нашего универсального ReactiveVariable мы можем теперь взять, и ввести ограничение на этот интерфейс примерно вот так

 public class ReactiveVariable<T> where T : IEquatable<T>

И благодаря такому ограничению теперь при сравнении будет использоваться Equals относящийся именно к интерфейсу IEquatable, а значит боксинги, анбоксинги и тп. нам больше не страшны

НО!

Такой вариант на самом деле неидеальный, и опять же вопрос к вам, дорогие подписчики, какие есть варианты почему? Чем может быть неудобно такое решение?

🔥 EqualityComparer - спасительный сравнятор объектов 🔥

Завершаем обсуждение вопроса сравнения объектов
Кто не читал про предыдущие два поста, то первая часть тут, а вторая тут

В предыдущий раз мы понял, что интерфейс IEquatable<T> очень хорошо подходит для сравнения объектов, но при этом ограничение универсального типа таким интерфейсом на нас не очень устраивает:

 public class ReactiveVariable<T> where T : IEquatable<T>

Тут есть ряд причин, которые мы разобрали в комментариях (сторонние типы могут не реализовывать этот интерфейс, обязательно надо будет на всех своих типах реализовать этот интерфейс, даже если нет особой необходимости и так далее)

Соответственно надо выдумывать что-то другое. И в итоге мы приходим к следующему типу из System.Collection.Generic:

public abstract class EqualityComparer<T> : IEqualityComparer<T>, IEqualityComparer
{
    protected EqualityComparer();

    public static EqualityComparer<T> Default { get; }

    public abstract bool Equals(T x, T y);
    public abstract int GetHashCode(T obj);
}

И соответственно мы можем наследоваться от этого EqualityComparerа и делать свои реализации сравнения для разных типов, переопределяя методы Equals и GetHashCode. Поэтому в реализации реактивности мы можем убирать вообще ограничение на IEquatable и переходить на использование таких вот сравняторов. Отсюда реализация меняется на использование IEqualityComparer

private IEqualityComparer<T> _comparer;

public ReactiveVariable(T value, IEqualityComparer<T> comparer)
{
    _value = value;
    _comparer = comparer;
}

public T Value
{
    get => _value;
    set
    {
        T oldValue = _value;

        _value = value;

        if (_comparer.Equals(oldValue, value) == false)
            Invoke(oldValue, value);
    }
}

Но, согласитесь, под каждый тип реализовывать свой сравнятор и пихать его при создании реактивной переменной - тухлая затея (просто далеко не всегда это нужно). Поэтому стоит обратиться к свойству Default у EqualityComparer. Оно делает следующее: автоматически возвращает подходящий компоратор для сравнения объектов указанного типа. И если тип реализует IEquatable (мы все таки не просто так про него говорили), то для сравнения как раз передается реализация с использованием Equals из этого интерфейса. И получается, что мы можем особо не заморачиваться с реализациями своих компораторов, если это не нужно, и использовать свойство Default, которое все сделает за нас. А для этого берем и добавляем в класс реактивности дополнительный конструктор следующего вида

   public ReactiveVariable(T value) : this(value, EqualityComparer<T>.Default)
   {
   }

И получается, если пользователю не хочется задавать свою реализацию компаратора, то будет просто использоваться дефолтный вариант, что нас полностью устраивает

Вот в целом и все секретики грамотного сравнения объектов. И на этом объяснение того, как именно мы пришли к итоговому решению можно закрывать)

p.s. постараюсь больше не душить такими статейками:)

Судя по реакциям большие длинные статьи заходят по хуже🤯

Нооо, что если завтра выйдет новый небольшой, но интересный видосик?)) Накидайте 🔥, если поддерживаете такую затею👍

🔥 Новое видео! Сделай игру безопаснее! 🔥

https://www.youtube.com/watch?v=hIE8gkcfwUI - смотреть тут:)

👉 Недавно разбирали базу по интерфейсу IDisposable, теперь углубляемся в эту тему и смотрим как можно сделать код удобнее и безопаснее:)

👉 Кроме того в этом видео объявил о хорошей для многих новости, так что обязательно посмотрите:)

Ну и ставьте 🔥 если ждете больше контента:)

🔥 Новый поток обучения! Что, где и когда?) 🔥

Наконец-то определились даты нового потока обучения на Unity adventure и я рад ими поделиться:)

🖥 Старт записи на поток будет 14 августа

🔜 Старт же самого обучения будет 8 сентября

✨ Причем этот поток будет особенным!) Несмотря на то, что обучение уже сейчас хорошо выстроено, я всегда ищу как его можно улучшить. Так вот следующим этапом станет добавление опции менторства на новом потоке - это позволит плотнее взаимодействовать с учениками, лучше доносить материал, оперативнее решать возникающие в ходе обучения вопросы и, в целом, такое усиление улучшит процесс обучения по всем фронтам. Я долгое время размышлял над этой возможностью, так как это довольно ответственное решение, с большим количеством возникающих вопросов, но смог по итогу прийти к наилучшему варианту, который позволит мне остаться интегрированным в обучение, и при этом сильно улучшит сервис

Но подробнее про новую опцию я расскажу позже в отдельном посте, а сейчас можете поставить 👍 к этому сообщению и подробнее ознакомиться с информацией и программой курса на сайте -> жмакнув сюда <-