Как сравниваются ссылочные типы в C#?

Ну вот, опять про эти ваши ссылки в C#. Слушай, тут как в жизни: можешь сравнивать, кто ты есть по паспорту (ссылка), а можешь — по тому, что из себя представляешь на самом деле (значение). И оба варианта имеют право на жизнь, просто надо понимать, когда что применять, а то так и до багов недалеко.

1. Сравнение по паспорту, то есть по ссылке (Reference Equality)

Тут всё просто, как три копейки. Берёшь две переменные и смотришь, не ведут ли они в одно и то же место в памяти, на один и тот же объект. Как два паспорта на одного человека.

• Оператор ==: Для большинства ссылочных типов (кроме строк, о них отдельно) он тупо сравнивает адреса. Один объект в памяти или два разных? Вот и весь вопрос.
• object.ReferenceEquals(a, b): Это уже явный, беспощадный спрос. Ты прямо говоришь: «Эй, CLR, да пошли они нахуй, все эти переопределения Equals, скажи мне честно — это один и тот же объект или нет?».

var obj1 = new object(); // Создали один кирпич
var obj2 = new object(); // Создали второй, такой же с виду, кирпич
var obj3 = obj1; // А это просто дали второе имя первому кирпичу

Console.WriteLine(obj1 == obj2); // False (бля, да это же два разных кирпича!)
Console.WriteLine(obj1 == obj3); // True (ну очевидно же, это один и тот же кирпич, на него просто две таблички)
Console.WriteLine(ReferenceEquals(obj1, obj2)); // False (я же сказал, разные!)

2. Сравнение по сути, то есть по значению (Value Equality)

А вот тут уже начинается магия, потому что тебе может быть похуй, один это объект или нет. Тебе важно, чтобы у них совпадали, например, имена, зарплаты или ещё какая-нибудь хуйня внутри. Чтобы это работало, надо объект научить сравнивать себя по смыслу.

Для этого нужно:

1. Переопределить дедовский метод object.Equals(object).
2. Обязательно, блядь, обязательно переопределить GetHashCode(), иначе все твои коллекции (типа Dictionary) сойдут с ума и будут работать как попало. Серьёзно, это частая причина ебучих багов.
3. (Опционально, но очень желательно) Реализовать интерфейс IEquatable<T>. Это чтобы не делать лишних приведений типов и не тратить ресурсы зря.

public class Person : IEquatable<Person>
{
    public string Name { get; set; }

    // Типобезопасное сравнение для умных
    public bool Equals(Person other)
    {
        if (other is null) return false; // Сравнивать с пустотой — себя не уважать
        return Name == other.Name; // Сравниваем по имени, как люди
    }

    // Старый дедовский способ, для совместимости
    public override bool Equals(object obj) => Equals(obj as Person);

    // ВАЖНО! Без этого — пиздец в хеш-таблицах.
    public override int GetHashCode() => Name?.GetHashCode() ?? 0;
}

// Проверяем
var person1 = new Person { Name = "Вася" };
var person2 = new Person { Name = "Вася" };

Console.WriteLine(person1 == person2); // False! Оператор == всё ещё сравнивает ссылки, если его отдельно не научить.
Console.WriteLine(person1.Equals(person2)); // True! Вот теперь используем нашу логику, и Васи оказались одинаковыми.

3. Особый случай: string — гений маскировки

Строка — она ссылочный тип, да. Но настолько важный и вездесущий, что для неё в языке сделали исключение. Операторы == и != для string перегружены так, чтобы сравнивать содержимое, а не адреса в памяти. Это как если бы паспорта на Василия Иванова со всего мира автоматически считались бы одним человеком. Удобно, но помни, что это исключение, а не правило.

Итог и главная рекомендация, чтобы не облажаться

Хочешь универсально и безопасно сравнить два объекта по значению, не вдаваясь в подробности, переопределили они что-то или нет? Используй EqualityComparer<T>.Default.Equals(a, b).

Этот штука — как умный следователь. Она сама посмотрит:

• Реализует ли твой тип IEquatable<T>? Если да, использует его.
• Нет? Может, ты переопределил object.Equals? Использует его.
• Вообще ничего не сделал? Ну тогда, извини, дружок, будем сравнивать по ссылкам.

Короче, надёжная штука. Пользуйся, и будет тебе счастье.