Цена полиморфизма

1. Введение

Полиморфизм выглядит очень заманчиво: вы пишете Base& b = derived; и дальше вызываете b.f(), а система сама «угадывает», какую реализацию взять. Это напоминает сервис доставки: вы не знаете, кто именно привезёт пиццу, но уверены, что она приедет. Только в программировании за доставку почти всегда платите вы — сложностью, ограничениями и иногда производительностью.

Давайте сразу договоримся: виртуальные методы — не зло, они полезны. Но они полезны примерно так же, как бензопила: если вы хотели нарезать хлеб — результат будет… запоминающимся. Наша цель сегодня — научиться видеть моменты, когда virtual реально приносит пользу, и моменты, когда он просто добавляет «ООП-обвязку», от которой код становится тяжелее, а ясности — не прибавляется.

2. Цена №1: виртуальный вызов — косвенность

Когда вы вызываете обычный метод, компилятор почти всегда точно знает, куда прыгать: «вот функция, вот адрес, поехали». С виртуальным методом мы сами просим компилятор: «Дорогой, не решай сейчас. Давай решим во время выполнения, по реальному типу объекта». Это и есть динамический полиморфизм: выбор реализации происходит в рантайме, а не при компиляции.

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

Мини-демонстрация, где виртуальность нужна (потому что мы реально используем базовый тип):

#include <iostream>
#include <string>

struct Report {
    virtual ~Report() = default;
    virtual std::string title() const { return "Report"; }
};

struct TaskReport : Report {
    std::string title() const override { return "Task report"; }
};

void print_title(const Report& r) {
    std::cout << r.title() << '\n'; // Task report
}

int main() {
    TaskReport tr;
    print_title(tr);
}

Здесь виртуальность «оправдана»: функция print_title специально принимает Report&, то есть работает полиморфно.

А вот пример, где виртуальность бесполезна, потому что мы и так работаем с конкретным типом:

#include <iostream>
#include <string>

struct TaskReport {
    std::string title() const { return "Task report"; }
};

int main() {
    TaskReport tr;
    std::cout << tr.title() << '\n'; // Task report
}

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

3. Цена №2: хранение объектов и владение

Пока у вас «обычные» объекты, вы живёте спокойно: std::vector<Task> tasks; — и всё. Но как только вы хотите хранить «разные реализации одного интерфейса» вместе, вы почти сразу упираетесь в то, что по значению хранить нельзя (здравствуйте, slicing), а значит надо хранить через указатели/умные указатели.

И вот тут цена становится очень практической: виртуальность почти всегда тянет за собой вопрос «кто владеет объектом?» и «когда он уничтожится?». Да, у нас есть std::unique_ptr, и это прекрасно (потому что delete вручную — это билет в цирк ужасов). Но даже с unique_ptr архитектура становится более многослойной: объекты живут в куче, создаются фабричными функциями, передаются по указателям, и вы обязаны следить за временем жизни аккуратно.

Сделаем маленький кусочек приложения. Пусть у нас есть задачи, и мы хотим строить по ним «отчёт» разными способами (подробный или компактный). Пока отчёт один — всё легко. Но допустим, отчётов несколько.

Сначала модель данных (мы делали похожее раньше, когда проходили struct + vector):

#include <string>

struct Task {
    int id{};
    std::string title;
    bool done{};
};

Теперь полиморфная база отчёта и две реализации:

#include <string>
#include <vector>

struct Report {
    virtual ~Report() = default;
    virtual std::string render(const std::vector<Task>& tasks) const {
        return "Empty report\n";
    }
};

struct DetailedReport : Report {
    std::string render(const std::vector<Task>& tasks) const override {
        return "Detailed tasks: " + std::to_string(tasks.size()) + "\n";
    }
};

И вторая:

#include <string>
#include <vector>

struct CompactReport : Report {
    std::string render(const std::vector<Task>& tasks) const override {
        return "Tasks: " + std::to_string(tasks.size()) + "\n";
    }
};

Чтобы «выбирать реализацию на лету», мы начинаем хранить отчёт через unique_ptr:

#include <iostream>
#include <memory>
#include <vector>

int main() {
    std::vector<Task> tasks = { {1, "Learn C++", false}, {2, "Drink tea", true} };

    std::unique_ptr<Report> rep = std::make_unique<DetailedReport>();
    std::cout << rep->render(tasks); // Detailed tasks: 2
}

Обратите внимание, как быстро простая идея «пусть отчёт будет разный» превратилась в необходимость думать об указателях и владении. И это нормально — но это и есть цена.

4. Цена №3: контракт, связность и сопровождение

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

Представьте, что в Report вы решили поменять сигнатуру:

• было: render(const std::vector<Task>&)
• стало: render(const std::vector<Task>&, bool show_done_only)

Теперь каждый наследник должен быть обновлён, и компилятор вас, конечно, «порадует» списком ошибок. Это хорошо (ошибки честные), но это цена: изменение контракта — массовое изменение кода.

Ещё один момент: базовый класс иногда начинает разрастаться «на всякий случай», потому что «вдруг пригодится». Так появляются базовые интерфейсы на 15 методов, из которых реальным наследникам нужно 2. В итоге часть методов переопределяется «пустышками», часть — кидает заглушки, и вы получаете объект, который формально подходит под Base, но по смыслу — нет. А дальше начинается классический ООП-спорт: «кто сильнее запутает код абстракциями».

5. Когда virtual действительно нужен

Как проверить необходимость полиморфизма

Иногда кажется, что правильный инженерный ответ — «всегда делай интерфейсы, вдруг расширим». Но в реальности полиморфизм стоит вводить тогда, когда есть конкретный сценарий, где он упрощает код уже сейчас.

Хорошая проверка звучит почти грубо: «Где именно в коде я буду держать Base& или Base* и вызывать виртуальные методы?». Если ответа нет, то вы строите «иерархию ради иерархии».

Посмотрим на наш пример с отчётом. Полиморфизм оправдан, если у нас действительно есть функция, которая не должна знать конкретный тип отчёта:

#include <iostream>
#include <string>
#include <vector>

void print_report(const Report& rep, const std::vector<Task>& tasks) {
    std::cout << rep.render(tasks);
}

А дальше где-то выше по коду мы выбираем реализацию (например, по настройке):

#include <memory>

std::unique_ptr<Report> make_report(bool detailed) {
    if (detailed) return std::make_unique<DetailedReport>();
    return std::make_unique<CompactReport>();
}

Если ваш код действительно выглядит так: «в одном месте выбираем, а дальше работаем через базовый тип» — полиморфизм на месте. Он делает код проще: нам не надо тащить if по всем участкам программы.

Три частых сценария «ООП ради ООП»

Очень легко «перестараться», особенно когда только-только выучил virtual и хочется применить его примерно везде, включая чайник и кота. Давайте разберём ситуации, где виртуальность обычно не даёт выигрыша.

Первая ситуация — тип всегда известен. Если в вашем приложении отчёт всегда только один (например, только подробный), то базовый класс Report не даёт пользы. Он даёт лишь обещание «потом расширим», но расплачиваться за обещание вы начинаете сразу: больше кода, больше файлов, больше связей.

Вторая ситуация — вариантов конечное и маленькое число, и это число не планируется расширять «плагинами». Например: режим вывода Compact или Detailed — и всё. В таких случаях часто проще иметь enum class и switch. Да, это не «ООП», зато это прозрачно: вы открыли switch и видите все варианты сразу.

Третья ситуация — вы используете наследование ради переиспользования кода, а не ради отношения «is-a». Это опасная дорожка. Если вам просто нужен общий код, то чаще помогает композиция: вынести общую часть в отдельный объект-поле и делегировать ему работу. Тогда у вас нет хрупкой иерархии, и изменения общей части не ломают контракт «базового интерфейса».

Мини-схема решения: нужен ли мне virtual?

Когда вы сидите вечером, пишете код, и рука тянется объявить базовый класс IWhatever (обычно именно так и называют, да), полезно сделать микро-паузу и пройтись по простой схеме. Это не «официальный стандарт», а практичный здравый смысл.

flowchart TD
    A["Есть разные варианты поведения?"] -->|Нет| B["Обычный класс/функция"]
    A -->|Да| C["Вариантов мало и набор фиксирован?"]
    C -->|Да| D["enum + switch или variant"]
    C -->|Нет| E["Нужно подставлять поведение как параметр?"]
    E -->|Да| F["lambda / std::function"]
    E -->|Нет| G["Реально нужен вызов через Base&/Base*?"]
    G -->|Да| H["virtual + override (полиморфизм)"]
    G -->|Нет| I["Скорее всего, virtual не нужен"]

Если вы честно дошли до пункта «реально нужен вызов через Base&/Base*» и ответили «да» — вы используете полиморфизм по назначению, а не как декоративную лепнину.

6. Альтернативы виртуальности

Когда говорят «без ООП никак», хочется показать на C++ и тихо спросить: «Вы точно уверены?». У нас есть несколько инструментов, которые нередко дают более простой и жёстко типизированный дизайн.

enum class + switch: когда вариантов мало и они фиксированы

Когда у вас два-три режима, switch часто выигрывает по читабельности. Сделаем тот же отчёт, но без базового класса.

#include <string>
#include <vector>

enum class ReportMode { Compact, Detailed };

std::string render_report(ReportMode mode, const std::vector<Task>& tasks) {
    if (mode == ReportMode::Detailed) return "Detailed tasks: " + std::to_string(tasks.size()) + "\n";
    return "Tasks: " + std::to_string(tasks.size()) + "\n";
}

Да, это условие. Но оно локальное и честное. Вам не нужно владение объектами отчёта, не нужно virtual, не нужны наследники. Если завтра режимов станет 10 — тогда можно пересмотреть решение.

Передай поведение как функцию: лямбды и std::function

Вы проходили лямбды и std::function, и это идеальная альтернатива «стратегии» без иерархий. Вместо базового класса «отчёт» мы можем просто передать функцию-рендерер.

#include <functional>
#include <string>
#include <vector>

using ReportFn = std::function<std::string(const std::vector<Task>&)>;

std::string run_report(const std::vector<Task>& tasks, const ReportFn& fn) {
    return fn(tasks);
}

И использование:

#include <iostream>

int main() {
    std::vector<Task> tasks = { {1, "Learn C++", false} };

    auto detailed = [](const std::vector<Task>& t) {
        return "Detailed tasks: " + std::to_string(t.size()) + "\n";
    };

    std::cout << run_report(tasks, detailed); // Detailed tasks: 1
}

Плюс этого подхода в том, что вы не тянете в код «семейство классов» и владение объектами. Минус — std::function тоже имеет стоимость (в том числе может выделять память), и это стоит помнить. Но в учебных и прикладных задачах часто это оказывается проще и достаточно быстро.

std::variant: полиморфизм без наследования

Вы уже видели std::variant и std::visit. Это особенно полезно, когда у вас есть фиксированный набор сущностей и вы хотите хранить их по значению, без указателей. Это буквально «полиморфизм без наследования»: вы храните «один из типов», а обрабатываете через visitor.

Мы не будем углубляться сейчас (чтобы не дублировать день про variant), но важно помнить идею: если набор реализаций закрыт и небольшой, variant часто убирает проблему владения и даёт строгую типизацию.

7. Типичные ошибки при использовании полиморфизма

Ошибка №1: добавлять virtual «на будущее», но не иметь ни одного места, где объект используется через Base&/Base*.
Это выглядит как подготовка к апокалипсису: вы строите бункер, но живёте в городе, где даже дождя толком не бывает. В результате код становится сложнее уже сейчас: появляется иерархия, unique_ptr, фабрики, а реальной выгоды нет. В такой ситуации лучше начать с простого конкретного типа, а полиморфизм добавить тогда, когда появится реальная точка расширения.

Ошибка №2: делать наследование ради переиспользования кода, хотя отношения «is-a» нет.
Соблазн понятный: «вынесу общие поля в базовый класс и всё будет красиво». На практике часто получается базовый класс-«свалка», от которого наследуются сущности с разным смыслом. Потом появляются странные методы в базе, которые половине наследников не нужны, а вторая половина переопределяет их «пусто». Если общая часть — это именно общий код, чаще лучше вынести её в отдельный объект и использовать композицию.

Ошибка №3: хранить полиморфные объекты по значению (и удивляться slicing).
Кажется логичным сделать std::vector<Base>, «ведь Derived же тоже Base». Но вы уже видели, чем это заканчивается: производная часть «срезается», виртуальное поведение исчезает, и вы получаете коллекцию самостоятельных Base. Если вам нужна полиморфная коллекция — придётся хранить через указатели (обычно std::unique_ptr<Base>), и это как раз часть цены полиморфизма.

Ошибка №4: путать «цена полиморфизма» с «виртуальность медленная, значит нельзя».
Новички иногда впадают в крайность: «виртуальные функции — зло, они медленные». В реальности виртуальность часто достаточно быстра для прикладного кода, а вот цена в дизайне (владение, связность, тестирование, контракты) обычно заметнее, чем цена в наносекундах. Правильный вопрос не «быстро ли это?», а «реально ли мне нужно такое расширение и такой способ использования типов?».

Ошибка №5: строить иерархию, а потом пытаться обойти её постоянными проверками конкретных типов.
Если у вас в коде появляется желание сделать что-то вроде «если это на самом деле DerivedA, то…» (неважно как именно), то вы, скорее всего, изначально выбрали не тот инструмент. Полиморфизм хорош тем, что позволяет не спрашивать «кто ты?», а просто сказать «сделай работу». Если вы всё равно вынуждены постоянно узнавать конкретный тип, значит либо контракт базы неверный, либо вместо иерархии вам нужен variant, либо вообще обычный switch по режиму.