#ifndef CAR_HPP
#define CAR_HPP

#include <string>

// Базовый класс
class Car {
protected:
    std::string brand;
    int speed;

public:
    Car(const std::string& brand);

    virtual void drive();   // метод (виртуальный, чтобы переопределять в наследниках)
    void stop();
};

#endif

#include "Car.hpp"
#include <iostream>

Car::Car(const std::string& brand) : brand(brand), speed(0) {}

void Car::drive() {
    speed = 60;
    std::cout << brand << " едет со скоростью " << speed << " км/ч\n";
}

void Car::stop() {
    speed = 0;
    std::cout << brand << " остановился\n";
}

#ifndef ELECTRIC_CAR_HPP
#define ELECTRIC_CAR_HPP

#include "Car.hpp"

// Класс-наследник
class ElectricCar : public Car {
private:
    int battery;

public:
    ElectricCar(const std::string& brand, int battery);

    void drive() override;   // переопределяем метод drive()
    void charge();
};

#endif

#include "ElectricCar.hpp"
#include <iostream>

ElectricCar::ElectricCar(const std::string& brand, int battery)
    : Car(brand), battery(battery) {}

void ElectricCar::drive() {
    if (battery > 0) {
        battery -= 10;
        speed = 80;
        std::cout << brand << " (электро) едет, батарея: " << battery << "%\n";
    } else {
        std::cout << brand << " не может ехать, батарея разряжена!\n";
    }

}

void ElectricCar::charge() {
    battery = 100;
    std::cout << brand << " зарядился до 100%\n";
}

#include "Car.hpp"
#include "ElectricCar.hpp"

int main() {
    Car lada("Lada");
    lada.drive();
    lada.stop();

    ElectricCar tesla("Tesla", 50);
    tesla.drive();
    tesla.charge();
    tesla.drive();

    return 0;
}

protected:
    std::string brand;
    int speed;

Поля brand и speed скрыты от внешнего мира. Снаружи (main.cpp) нельзя написать:

lada.speed = 200; // Ошибка! Доступ закрыт.

Зато можно вызвать lada.drive(), и машина сама решит, что сделать со скоростью.

👉 Инкапсуляция даёт надёжность: объект нельзя «сломать» напрямую, а работать с ним можно только через методы.

3) 🧪 Экземпляр класса: память и жизнь объекта

Экземпляр создаётся из класса и хранит свои данные отдельно от других экземпляров:

Car a("Lada"); 
Car b("Volvo"); // a и b — разные объекты с разными полями

Где он живёт:

• 🧷 Стек — создаёшь просто как переменную, деструктор вызовется сам при выходе из блока.

Car lada("Lada"); // автоматическое время жизни

• 📦 Куча (heap) — через new/delete или «умные» указатели.

Car* p = new Car("Lada"); 
p->drive(); 
delete p; // не забыть!

4) 🧬 Наследование

Создаём новый класс на базе старого: получаем всё старое и добавляем своё.

class Car { /* базовый класс */ }; 
class ElectricCar : public Car { /* +battery, +charge() */ };

5) 🎭 Полиморфизм

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

В Car:

virtual void drive();

В ElectricCar:

void drive() override;

Теперь, если у тебя есть указатель/ссылка на Car, но в нём лежит ElectricCar, вызов drive() выполнит именно версию из ElectricCar.

Car* car = new ElectricCar("Tesla", 50);
car->drive(); // вызовется ElectricCar::drive()

👉 Это и есть полиморфизм: одна команда (drive) → разное поведение в зависимости от того, какой объект.

Вот еще пример:

#include <iostream>

class Base {
public:
    virtual void hello() { std::cout << "Base\n"; }
};

class Child : public Base {
public:
    void hello() override { std::cout << "Child\n"; }
};

int main() {
    Base* b = new Child();
    b->hello(); // вывод: Child
}

6) ⚙️ Под капотом: vptr и vtable

Если в классе есть virtual-метод, компилятор кладёт в объект скрытый указатель vptr на таблицу функций vtable его реального типа. Вызов идёт: объект → vptr → vtable → адрес нужной функции.

Base* p = new Child();

/* Объект Child в куче
   ┌───────────────────────────────┐
   │ поля Base/Child ...          │
   │ vptr ────────────────────┐   │
   └──────────────────────────┼───┘
                              ▼
                     [vtable для Child]
                      ├─ &Child::hello
                      ├─ &Child::~Child
                      └─ ... другие virtual
*/

p->hello(); // берём vptr → таблица Child → слот hello → Child::hello()

Тогда можно работать с IVehicle* без знания деталей: IVehicle* v = new ElectricCar(...); v->drive();

Простое объяснение vptr и vtable

Когда ты используешь virtual в C++ (например, virtual void drive() = 0 в IVehicle или virtual void drive() в Car), компилятор включает механизм динамического полиморфизма. Это значит, что при вызове метода через указатель или ссылку (типа IVehicle* v = new ElectricCar(); v->drive();) программа должна в момент выполнения понять, какую именно версию метода вызвать (Car::drive() или ElectricCar::drive()). Вот тут и появляются vptr и vtable.

• vptr (virtual pointer, указатель на виртуальную таблицу): Это скрытый указатель, который компилятор добавляет в каждый объект класса, где есть хотя бы одна виртуальная функция. Он указывает на таблицу виртуальных функций (vtable) для этого класса.
• vtable (virtual table, таблица виртуальных функций): Это таблица, где хранятся адреса всех виртуальных методов для конкретного класса. Каждый класс с виртуальными функциями имеет свою vtable.

Как это работает?

1. Когда ты создаёшь объект, например, ElectricCar, компилятор кладёт в него vptr, который указывает на vtable класса ElectricCar.
2. В vtable для ElectricCar лежат адреса методов, например, &ElectricCar::drive и &ElectricCar::stop.
3. Когда ты вызываешь v->drive() через указатель IVehicle*, программа смотрит на vptr объекта, находит его vtable и вызывает нужный метод (в данном случае ElectricCar::drive).

Аналогия для "дураков" (как мы любим): Представь, что объект — это человек, а vptr — это его визитная карточка, на которой написан номер телефона справочной службы (vtable). Когда ты звонишь по номеру (v->drive()), справочная соединяет тебя с нужным человеком (методом ElectricCar::drive), даже если ты звонишь через общий номер (IVehicle*).

7) 🧩 Абстракция: интерфейсы как меню в ресторане

Абстракция — это когда ты говоришь: "Мне пох, как это работает, главное, чтобы работало!" Ты задаёшь список того, что объект должен уметь, но не лезешь в детали, как он это делает. В C++ это называется интерфейсом — списком методов, которые класс обязан реализовать.

Похоже на прототипы функций в заголовочном файле (типа void drive(); в начале программы)? Отчасти да, но интерфейс — это не просто прототипы, а контракт для классов. Он говорит: "Если ты хочешь быть транспортом, ты должен уметь drive() и stop(), а как — твоё дело".

Аналогия: Представь, что ты в ресторане. Меню — это интерфейс, где написано: "Можно заказать суп и десерт". Повар (класс) готовит их по-своему: один делает борщ и тирамису, другой — щи и мороженое. Ты просто заказываешь "суп" и не думаешь, как его готовят. Абстракция — это и есть такое меню.

Вернёмся к нашему коду. Мы можем сделать интерфейс для транспорта:

#include <iostream>
#include <string>
struct IVehicle {
    virtual void drive() = 0; // "Ты обязан уметь ехать!"
    virtual void stop() = 0;  // "Ты обязан уметь останавливаться!"
    virtual ~IVehicle() = default; // Для корректной очистки памяти
};
class Car : public IVehicle {
public:
    Car(const std::string& brand) : brand(brand), speed(0) {}
    void drive() override { std::cout << brand << " едет со скоростью 60 км/ч\n"; }
    void stop() override { std::cout << brand << " остановился\n"; }
private:
    std::string brand;
    int speed;
};
class ElectricCar : public IVehicle {
public:
    ElectricCar(const std::string& brand, int battery) : brand(brand), battery(battery) {}
    void drive() override {
        if (battery > 0) {
            battery -= 10;
            std::cout << brand << " (электро) едет, батарея: " << battery << "%\n";
        } else {
            std::cout << brand << " не может ехать, батарея разряжена!\n";
        }
    }
    void stop() override { std::cout << brand << " остановился\n"; }
private:
    std::string brand;
    int battery;
};

Чем это отличается от прототипов функций?

• Прототипы (типа void drive(); в .h файле) — это просто объявления функций, чтобы компилятор знал, что они где-то есть. Они не связаны с классами и не дают гибкости ООП.
• Интерфейс — это контракт для классов. IVehicle говорит: "Все, кто наследуется от меня, должны иметь drive() и stop()". Плюс он позволяет полиморфизм: ты вызываешь v->drive(), и код сам решает, какую версию метода выполнить.

Что тут происходит?

• IVehicle — это как меню: "Все транспортные средства должны уметь drive() и stop()".
• Car и ElectricCar — это повара, которые готовят эти "блюда" по-своему.
• Ты работаешь через указатель IVehicle*, но не знаешь, что там внутри — машина, электромобиль или трактор. И тебе это не важно!

Почему это круто?

• Можно добавить новый класс, например Bicycle, унаследовать от IVehicle, и код будет работать без изменений.
• Ты не ломаешь голову о том, как именно drive() реализован — главное, что он есть.
• Это позволяет писать гибкий код, где разные классы могут работать через один интерфейс.

BBC-пересказ: Абстракция — это как заказать пиццу: ты говоришь "хочу пиццу", а как её испекут — не твоя забота. Интерфейс задаёт, что должно быть, а классы решают, как это сделать.

About *m_about = nullptr;
m_about = new About;
m_about->show();

QWidget* w = new QPushButton("Нажми меня"); 
w->show();

#include 
#include 
#include 

class MyButton : public QPushButton {
    Q_OBJECT
public:
    using QPushButton::QPushButton;
protected:
    void paintEvent(QPaintEvent* e) override {
        QPainter painter(this);
        painter.setBrush(Qt::red); // Красим кнопку в красный
        painter.drawRect(rect());  // Рисуем прямоугольник
        QPushButton::paintEvent(e); // Вызываем стандартную отрисовку
    }
};

QWidget* w = new MyButton("Нажми меня");
w->show(); // Вызовет QWidget::show() — окно появится