Какие виртуальные методы предоставляет базовый класс Object в C# и для чего они используются?

А, ну вот, System.Object, мать его! Корень всей этой нашей иерархии в C#, как дед на печи — все от него пляшут, и ссылочные, и значимые, если их в бокс запихнуть. А внутри у него, у этого деда, есть несколько виртуальных методов, которые он как бы предлагает: «Внучата, перепишите на свой лад, а то у меня реализация так себе».

Вот эти самые виртуальные методы, на которые надо глаз положить:

1. public virtual bool Equals(object? obj)

   • Зачем нужен: Чтобы понять, равны ли два объекта по смыслу, а не просто потому что это одна и та же ссылка в памяти. По умолчанию для классов == сравнивает именно ссылки, а это часто не то, что надо.
   • Когда в него лезть: Когда у тебя есть свой класс, и два разных экземпляра могут считаться одинаковыми. Например, объект Деньги с суммой 100 рублей и валютой USD должен быть равен другому такому же объекту, даже если они в памяти в разных местах. Важное правило, которое все хуярят: если переопределил Equals, тут же, блядь, переопределяй и GetHashCode(), иначе потом будешь искать, почему в Dictionary всё ебется.

   • Пример, чтобы было понятнее:

     public class Товар
     {
     public int Айди { get; set; }
     public string Название { get; set; }
     
     public override bool Equals(object obj)
     {
         // Если obj — это Товар, и айдишники совпали, то это один и тот же товар по нашей логике
         return obj is Товар другой && this.Айди == другой.Айди;
     }
     // GetHashCode тоже надо! Смотри ниже.
     }

2. public virtual int GetHashCode()

   • Зачем нужен: Чтобы быстро находить объекты в хеш-таблицах, типа Dictionary или HashSet. Это как номер ячейки в гигантском шкафу.
   • Главные правила, которые нарушать — себя не уважать:
     1. Если два объекта по Equals равны, то их хеш-коды обязаны быть одинаковыми. Иначе в коллекциях начнётся пиздец, объекты потеряются.
     2. Хеш-код должен быть стабильным, пока объект живёт. Нельзя, чтобы он менялся, пока объект лежит, например, в словаре.
     3. Для разных объектов хорошо бы возвращать разные коды, чтобы не было коллизий и поиск был быстрым.
   • Пример (продолжаем издеваться над Товаром):

     public override int GetHashCode() => Айди.GetHashCode(); // Всё просто, хеш-код товара — это хеш его айди.

3. public virtual string? ToString()

   • Зачем нужен: Чтобы получить человекочитаемую строку из объекта. По умолчанию он выдаёт полное имя типа, что полезно, как паровоз в огороде.
   • Когда переопределять: Почти всегда для своих классов! Когда ты в отладке смотришь на значение переменной или пишешь Console.WriteLine(myObject), хочется видеть осмысленные данные, а не YourNamespace.SomeClass. Широко используется в интерполяции строк.
   • Пример:

     public override string ToString() => $"Товар {{ Айди = {Айди}, Название = {Название} }}";

А ещё есть методы невиртуальные, статические:

• public static bool ReferenceEquals(object? objA, object? objB)
  • Этот товарищ всегда, при любых раскладах, проверяет, одна ли это ссылка в памяти. Даже если ты перегрузил оператор ==. Полезно, когда нужно на 100% убедиться, что это один и тот же физический объект.
• public static bool Equals(object? objA, object? objB)
  • Статический помощник, который не паникует от null и внутри вызывает уже виртуальный Equals. Удобная обёртка.

И один защищённый метод, как семейная реликвия:

• protected object MemberwiseClone()
  • Делает поверхностную копию объекта. То есть скопирует все поля: для чисел — значения, для ссылок на другие объекты — скопирует только ссылку (сам объект-прицеп клонирован не будет). Иногда полезно, но глубоко не копает.

Ну и примерчик в студию, чтобы закрепить:

var список1 = new List<int>() { 1, 2, 3 };
var список2 = список1; // Скопировали ссылку, это один и тот же объект
var список3 = new List<int>() { 1, 2, 3 }; // Создали новый объект, но с такими же данными

Console.WriteLine(Object.ReferenceEquals(список1, список2)); // True (одна и та же банка сгущёнки)
Console.WriteLine(Object.ReferenceEquals(список1, список3)); // False (две разные банки)
Console.WriteLine(список1.Equals(список3)); // У List<T> Equals переопределён — может вернуть True (сравнивает содержимое)

Console.WriteLine(список1.GetType().Name); // "List`1"
Console.WriteLine(список1.GetType().FullName); // "System.Collections.Generic.List`1[[System.Int32...]]" — вот это уже полное имя с деталями

Итог, блядь: Если пишешь свой класс, который представляет какую-то сущность (не просто служебный класс на один вызов), то переопределение Equals, GetHashCode и ToString — это не прихоть, а признак того, что ты не мудак и думаешь о том, как твоим классом будут пользоваться. Без этого он будет вести себя тупо и непредсказуемо в стандартных коллекциях.