Связь полиморфизма с абстрактными методами

1. Введение

Давайте вернемся к нашему зоопарку. У нас есть базовый класс Animal (Животное) и его производные: Dog (Собака), Cat (Кошка), Fish (Рыба).

В предыдущих лекциях мы добавили в Animal виртуальный метод MakeSound():

public class Animal
{
    public string Name { get; set; }
    public int Age { get; set; }

    public virtual void MakeSound() // Виртуальный метод
    {
        Console.WriteLine("Какое-то животное издает звук."); // Реализация по умолчанию
    }

    public void Sleep() // Обычный метод
    {
        Console.WriteLine($"{Name} спит.");
    }
}

public class Dog : Animal
{
    public override void MakeSound() // Переопределяем звук для собаки
    {
        Console.WriteLine("Гав-гав!");
    }
}

public class Cat : Animal
{
    public override void MakeSound() // Переопределяем звук для кошки
    {
        Console.WriteLine("Мяу!");
    }
}

Это здорово работает! Когда мы создаем Dog или Cat и вызываем MakeSound(), мы слышим их уникальные звуки. Но что, если мы создадим просто Animal?

Animal genericAnimal = new Animal();
genericAnimal.Name = "Неизвестное существо";
genericAnimal.MakeSound(); // Выведет: "Какое-то животное издает звук."

Выглядит логично. Но иногда бывает так, что базовая реализация по умолчанию просто не имеет смысла. Что, если Animal – это не конкретное животное, а скорее концепция? "Животное" как таковое не издает конкретный звук, это делают уже конкретные виды животных. Или, представьте, что у нас есть класс Shape (Фигура) и у него есть метод CalculateArea() (ВычислитьПлощадь). Какую площадь должен вычислять просто Фигура? Никакую! Площадь есть у Круга, у Квадрата, но не у абстрактной "Фигуры".

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

2. Абстрактные классы: Когда чертеж еще не дом

Представьте, что вы архитектор, и вы создаете чертеж типового дома. Но не просто дома, а "Концептуального Дома". У него есть общие черты: стены, крыша, фундамент. Но вы еще не знаете, будет ли это одноэтажный коттедж или многоэтажный небоскреб. Какие-то части чертежа будут конкретными (например, высота потолков на первом этаже), а какие-то – пока только намеком (например, "количество этажей", которое будет определено позже).

В мире C# такой "Концептуальный Дом" называется абстрактным классом.
Абстрактный класс – это класс, который помечен ключевым словом abstract.

public abstract class Animal // Теперь Animal - абстрактный класс
{
    // ...
}

Ключевая особенность абстрактных классов:

• Их нельзя создать напрямую. Вы не можете написать new Animal(). Почему? Потому что Animal – это теперь нечто неопределенное, концепция. Вы не можете построить "Концептуальный Дом", вы можете построить только конкретный коттедж или небоскреб.
  Если вы попробуете new Animal(), компилятор сразу же даст вам по рукам:

  Cannot create an instance of the abstract type or interface 'Animal'
  (Невозможно создать экземпляр абстрактного типа или интерфейса 'Animal')

  Это очень важное ограничение!
• Они могут содержать абстрактные члены. А вот это уже самое интересное!

3. Абстрактные методы: контракт без реализации

Если абстрактный класс – это "Концептуальный Дом", то абстрактный метод – это та его часть, которая на чертеже указана как "сделать это", но без конкретных инструкций "как". Например, "Построить фундамент" – это обязательная часть дома, но конкретные размеры и материалы фундамента зависят от типа дома.

Абстрактный метод – это метод, который:

• Помечен ключевым словом abstract.
• Не имеет тела (то есть, нет блока кода {}). Он заканчивается точкой с запятой ;.
• Может быть объявлен только внутри абстрактного класса.

Давайте сделаем наш метод MakeSound() абстрактным:

public abstract class Animal // Мы сделали Animal абстрактным
{
    public string Name { get; set; }
    public int Age { get; set; }

    public abstract void MakeSound(); // Вот он, абстрактный метод! Нет тела!

    public void Sleep() // Этот метод остался обычным, "конкретным"
    {
        Console.WriteLine($"{Name} спит.");
    }
}

Посмотрите, как изменился MakeSound()! У него больше нет фигурных скобок и реализации по умолчанию. Теперь он просто говорит: "Любое животное обязано уметь издавать звук. А как именно – пусть решают те, кто унаследует от меня."

Важное правило: Если ваш класс наследуется от абстрактного класса и не является сам абстрактным, он обязан переопределить (с помощью override) все абстрактные методы базового класса. Это не опция, это требование, контракт! Компилятор C# очень строг в этом вопросе. Если вы забудете, он тут же вам об этом напомнит:

public class Dog : Animal // Обычный, неабстрактный класс
{
    // ОШИБКА КОМПИЛЯЦИИ!
    // 'Dog' does not implement inherited abstract member 'Animal.MakeSound()'
    // (Класс 'Dog' не реализует унаследованный абстрактный член 'Animal.MakeSound()')
    // Компилятор ждет от нас MakeSound() с override!
}

Чтобы избавиться от ошибки, Dog и Cat должны обязательно переопределить MakeSound():

public class Dog : Animal
{
    public override void MakeSound() // Обязательно переопределяем!
    {
        Console.WriteLine("Гав-гав!");
    }
}

public class Cat : Animal
{
    public override void MakeSound() // И здесь тоже!
    {
        Console.WriteLine("Мяу!");
    }
}

Сравнение virtual, abstract и override

4. Полиморфизм в действии с абстрактными методами

Вот теперь начинается самое интересное! Мы уже знаем, что полиморфизм позволяет нам работать с объектами разных производных классов через общую ссылку на базовый класс. И это прекрасно работает даже тогда, когда базовый класс — абстрактный!

Хотя мы не можем создать экземпляр Animal напрямую (помните, new Animal() выдаст ошибку), мы можем использовать тип Animal в качестве ссылки на объекты производных классов. Это очень мощно!

Давайте продолжим наш зоопарк. Представим, что у нас есть ферма, и на ней живут разные животные. Мы хотим, чтобы каждое животное издало свой звук.

using System;

// Абстрактный класс Animal
public abstract class Animal
{
    public string Name;
    public int Age;
    public Animal(string name, int age) { Name = name; Age = age; }
    public abstract void MakeSound();
    public void Sleep() { Console.WriteLine($"{Name} спит."); }
}

public class Dog : Animal
{
    public Dog(string name, int age) : base(name, age) { }
    public override void MakeSound() { Console.WriteLine("Гав-гав!"); }
}

public class Cat : Animal
{
    public Cat(string name, int age) : base(name, age) { }
    public override void MakeSound() { Console.WriteLine("Мяу!"); }
}

public class Fish : Animal
{
    public Fish(string name, int age) : base(name, age) { }
    public override void MakeSound() { Console.WriteLine("Буль-буль"); }
}

class Program
{
    static void Main()
    {
        Animal[] animals = {
            new Dog("Шарик", 3),
            new Cat("Мурзик", 5),
            new Fish("Немо", 1)
        };

        foreach (Animal animal in animals)
        {
            Console.WriteLine($"\nПривет, я {animal.Name}, мне {animal.Age} лет.");
            animal.MakeSound();
            animal.Sleep();
        }
    }
}

Что происходит в этом коде?

1. Мы объявили Animal как abstract class. Это говорит компилятору: "Этот класс – шаблон, его самого нельзя создать, но от него можно наследоваться".
2. Мы объявили public abstract void MakeSound(); внутри Animal. Это заявляет: "Любой класс, который наследуется от Animal (и не является сам абстрактным), обязан реализовать метод MakeSound()". Это наш контракт!
3. Dog, Cat, и Fish безропотно следуют этому контракту, переопределяя MakeSound() со своей уникальной реализацией. Если бы мы забыли это сделать хотя бы для одного из них, компилятор бы не пропустил наш код.
4. В методе Main мы создаем массив Animal[]. Несмотря на то, что Animal абстрактный, массив может хранить ссылки на объекты производных классов (Dog, Cat, Fish), потому что они являются Animal!
5. Когда мы проходим по массиву в цикле foreach и вызываем animal.MakeSound(), благодаря полиморфизму C# "знает", какой именно MakeSound() вызвать: Dog.MakeSound(), Cat.MakeSound() или Fish.MakeSound(). Вызывается тот метод, который относится к фактическому типу объекта, на который ссылается Animal в данный момент, а не к типу ссылки. Это и есть вся прелесть полиморфизма!
6. А вот animal.Sleep() вызывает конкретную реализацию из базового класса Animal, потому что этот метод не был помечен как virtual или abstract, и его не переопределяли в дочерних классах.

5. Зачем это нужно в реальной жизни?

"Хорошо, зоопарк, животные... А где это пригодится, когда я буду писать реальное приложение для банка или магазина?" — спросите вы. И это отличный вопрос! Абстрактные классы и методы – это мощнейший инструмент для проектирования гибких и расширяемых систем.

Принуждение к реализации контракта: Это главное преимущество. Представьте, что вы разрабатываете фреймворк для платежных систем. У вас есть базовый abstract class PaymentProcessor (Обработчик платежей). И вы точно знаете, что любой обработчик платежей должен уметь ProcessPayment() (Обработать платеж), RefundPayment() (Вернуть платеж) и CheckStatus() (Проверить статус). Но как именно это происходит для PayPal, для банковской карты или для Bitcoin — совершенно разные вещи.
Вы объявляете эти методы как abstract в PaymentProcessor.

public abstract class PaymentProcessor
{
    public abstract bool ProcessPayment(decimal amount, string currency, string cardNumber);
    public abstract bool RefundPayment(string transactionId);
    public abstract string CheckStatus(string transactionId);
    // ... другие методы, которые могут быть и конкретными, например, логирование
    public void LogTransaction(string message)
    {
        Console.WriteLine($"[LOG]: {message}");
    }
}

public class PayPalProcessor : PaymentProcessor
{
    public override bool ProcessPayment(decimal amount, string currency, string cardNumber)
    {
        // Здесь сложная логика работы с API PayPal
        Console.WriteLine($"PayPal: обрабатываем {amount} {currency}...");
        return true;
    }
    public override bool RefundPayment(string transactionId) { /* ... */ return true; }
    public override string CheckStatus(string transactionId) { /* ... */ return "Completed"; }
}

public class CreditCardProcessor : PaymentProcessor
{
    public override bool ProcessPayment(decimal amount, string currency, string cardNumber)
    {
        // Здесь логика работы с банком-эквайером
        Console.WriteLine($"CreditCard: {amount} {currency} с карты {cardNumber.Substring(0,4)}XXXX...");
        return true;
    }
    public override bool RefundPayment(string transactionId) { /* ... */ return true; }
    public override string CheckStatus(string transactionId) { /* ... */ return "Processing"; }
}

Теперь любой разработчик, который захочет создать новый обработчик платежей (например, BitcoinProcessor), будет вынужден реализовать все эти три метода. Он не сможет случайно забыть про RefundPayment(), потому что компилятор не даст ему этого сделать! Это обеспечивает консистентность в вашей системе.

Гибкость и расширяемость: Вы можете написать код, который работает с PaymentProcessor, не зная, какая именно конкретная реализация будет использоваться. Например, в коде корзины интернет-магазина вы просто вызываете currentProcessor.ProcessPayment(), а система сама подставляет нужный обработчик в зависимости от выбранного пользователем способа оплаты. Завтра появится новый способ оплаты – вы просто создаете новый класс, наследуетесь от PaymentProcessor, реализуете абстрактные методы, и ваш основной код в магазине даже не придется менять!

Избегание пустых реализаций: Если бы мы использовали virtual методы вместо abstract, нам пришлось бы давать им пустую реализацию по умолчанию, что могло бы быть misleading (вводящим в заблуждение). abstract явно говорит: "Здесь нет реализации, и ее быть не может – идите к наследникам!"

Улучшение архитектуры кода: Абстрактные классы помогают четко разделить общую логику и специфическую логику. Общая (например, LogTransaction в PaymentProcessor) живет в базовом классе, а специфическая (как ProcessPayment) — в производных. Это делает код более читаемым, поддерживаемым и тестируемым. Это позволяет дизайнерам фреймворков и библиотек определять "точки расширения", которые пользователи их библиотек должны заполнить.

6. Распространённые ошибки и тонкости

Ошибка №1: попытка создать экземпляр абстрактного класса.
Это всегда ошибка компиляции. Абстрактный класс — это концепция, а не конкретный объект. Вы можете использовать его как тип ссылки, но не можете написать new Animal().

Ошибка №2: забыли переопределить абстрактный метод.
Если производный класс не является абстрактным, он обязан реализовать все abstract-методы базового класса. Иначе — ошибка компиляции. Единственный способ обойти это — сделать производный класс тоже абстрактным, но чаще всего это не то, что вы хотите.

Ошибка №3: путаница между abstract и virtual.
abstract обязывает переопределить метод, он не имеет тела. virtual предоставляет реализацию по умолчанию и может быть переопределён. Нельзя объявлять abstract-метод с телом или virtual-метод без тела — это синтаксическая ошибка.

Ошибка №4: использование new вместо override.
Если вы не используете override, а просто создаёте метод с тем же именем в наследнике, вы не переопределяете, а скрываете метод базового класса. Это приведёт к неожиданному поведению при полиморфных вызовах: будет вызываться метод из базового класса.

public class Base
{
    public void DoSomething() { Console.WriteLine("Base"); }
}

public class Derived : Base
{
    public new void DoSomething() { Console.WriteLine("Derived"); }
}

Base obj = new Derived();
obj.DoSomething(); // Выведет: Base

2

Задача

C# SELF, 21 уровень, 4 лекция

Недоступна

Создание абстрактного класса и его реализация

Создание абстрактного класса и его реализация

Открыть

2

Задача

C# SELF, 21 уровень, 4 лекция

Недоступна

Полиморфизм с абстрактными методами

Полиморфизм с абстрактными методами

Открыть

1

Опрос

Понятие полиморфизма, 21 уровень, 4 лекция

Недоступен

Понятие полиморфизма

Полиморфизм и перегрузка методов

Открыть