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

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

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

 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 сентября

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

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

🙁 Я задолжал... 🙁

И самое ужасное, что задолжал я вам, друзья.

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

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

Для видеороликов есть довольно много идей на ближайшее время, так что вместо этого я предлагаю завтра в 18:30 собраться на стриме, пообщаться и провести ревью нескольких работ. Я отобрал варианты, которые будет полезно и интересно посмотреть довольно широкому кругу разработчиков, поэтому, думаю, получится довольно интересный стрим

Надеюсь на ваше понимание и поддержку 🔥 под этим постом

p.s. ждите завтра ссылочку✨

✨ Ревью кода подписчиков уже сегодня ✨

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

🔜 Начало в 18:30 МСК

👀 Где смотреть?

✔️ Можно на ютубе
✔️ Можно на твиче

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

🔥 Через 10 минут стартуем! 🔥

🔣 Нужна ли стейт машина в игре?

🔣 Что делать с главным меню?

🔣 Нужны ли контейнеры и прочие усложнения?

Сегодня разберем кучу разных вопросов на примере ваших проектов!)

Поэтому подключайтесь:

👀 СМОТРЕТЬ НА YOUTUBE

👀 СМОТРЕТЬ НА TWITCH

✨ Поехали! ✨

Спасибо всем кто пришел! Было круто:) Пошел отдыхать😅

⚡️С 0 ДО JUNIOR+ К 2026 ГОДУ. Детальный roadmap ⚡️

На последнем стриме мы договорились, что я подготовлю подробный вебинар с дорожной картой развития в сфере геймдева и вот анонс данного мероприятия!

🔜 Когда?

12 и 13 августа, в 19:00 по МСК на прямой трансляции (вебинар пройдет в 2 дня, так как информации будет реально много)

🖥 Как попасть?

Для регистрации на вебинар нужно просто перейти к боту ТЫКНУВ СЮДА и нажать кнопочку "попасть на вебинар". Ссылка на трансляцию автоматически придет в день вебинара

👀 Что будет?

Впереди нас ждет 2 дня четких инструкций, следуя которым ты поймешь:

👉 Как продуктивнее всего изучать C# + Unity
👉 С какого этапа можно начинать проходить собеседования
👉 Как делать пет проекты, чтобы не стоять на месте и показывать релевантный опыт в резюме
👉 Нужно ли засорять голову паттернами?
👉 Насколько необходимо знание архитектуры junior разработчику и как вообще постигать эту область

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

🎁 Ну и конечно же, по традиции будут подарки:

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

❗️А также для тех, кто будет вживую присутствовать на мероприятии откроется предварительная запись на Unity adventure, чтобы вы могли спокойно забронировать место и получить особый крутой бонус (скоро отдельно расскажу какой)

Думаю, получится очень крутой вебинар, который зарядит вас энергией и задаст вектор развития к новому году! Буду всех ждать🥰